Support the 8-bit (0-255) .colorset input method (follow-up to #471)

[arulagarwal]

Why

#471 (thanks @haaaaaaarshs!) fixed the common case — .colorset channels authored with Xcode's 8-bit Hexadecimal input method (0x..) now parse correctly instead of rendering black. Following up on @marcprux's note on #468, this rounds out the last numeric Input Method: 8-bit (0–255).

Xcode's "8-bit (0–255)" method writes each channel as a bare integer (e.g. "148"). That currently falls through to Double("148") = 148.0, which clamps to white — so a color authored with that method still renders wrong. This normalizes a bare integer (one with no decimal point) by /255, matching the hex path.

There also isn't yet any test coverage around colorset component parsing, so this adds fixtures + render tests for all three numeric methods (hexadecimal, 8-bit 0–255, floating point) — all encoding the same color — to guard against regressions.

What

• ColorComponents.parseComponent: adds one branch — a bare integer (no .) is treated as an 8-bit (0–255) value and normalized /255. The hexadecimal and floating-point paths are unchanged.
• Adds HexColor / IntColor / FloatColor fixtures (the same #04F188 encoded via each method) and render tests asserting all three agree.

A note on the tests: they're DISABLED-prefixed because decoding a bundled component .colorset throws a kotlin-reflect IllegalAccessException under the Robolectric unit runner (it can't access the generated DecodableCompanion for the nested ColorSet types), so it falls back to gray there. This is a pre-existing test-runner limitation independent of this change — the tests pass on a real device/emulator, and the parsing logic is additionally covered by a standalone check.

Before / After evidence

Standalone check of the parsing over all three methods (same color):

hex  0x04 / 0xF1 / 0x88   -> 0.0157 / 0.9451 / 0.5333
8bit 4    / 241  / 136    -> 0.0157 / 0.9451 / 0.5333   (before: "148"-style values clamped to white)
float 0.0157 / 0.9451 / 0.5333 -> unchanged

swift test --filter ColorTests passes; skip test --filter ColorTests builds/transpiles and the suite stays green.

Acceptance criteria

• Test added for the new behavior (8-bit fixtures + render tests) plus hex/float regression fixtures
• Existing test suite passes (swift test; skip test on Robolectric)
• Follows project style (extends the existing parseComponent, reusing Fix hex color component parsing #471's helpers)
• No breaking changes (hex and floating-point paths unchanged)

Refs #146, builds on #471.

---

Skip Pull Request Checklist:

• REQUIRED: I have signed the Contributor Agreement
• REQUIRED: I have tested my change locally with swift test
• OPTIONAL: I have tested my change on an iOS simulator or device
• OPTIONAL: I have tested my change on an Android emulator or device
• REQUIRED: I have checked whether this change requires a corresponding update in Skip Fuse UI — none needed (internal colorset parsing; no public API change)
• OPTIONAL: I have added an example of any UI changes to the Showcase sample app

---

• AI was used to assist with this PR. How: I used Claude Code to extend the parser, add fixtures/tests, and run the suite. Verification: I read and understood every line, confirmed the 8-bit normalization against the hex/float encodings of the same color, and ran swift test + skip test plus a standalone logic check.

[arulagarwal]

Hi @marcprux — this follow-up PR adds support for the 8-bit (0–255) Input Method and includes the fixture/render tests that #471 didn't cover (mentioned in my comment on #146). CI is green and CLA is signed. Would appreciate a review when you have a chance — happy to address any feedback. Thanks!

[marcprux]

The implementation looks good. However, all the tests are "DISABLED", so they should either be removed (along with the therefore unnecessary .colorset/Contents.json additions), or (ideally) be made to work.

I'm not entirely sure why the tests need to be disabled, because they look like they ought to work to me. If it is just some issue with robolectric and isn't present in the Android emulator (as run by the CI), perhaps they could just be gated behind #if !ROBOLECTRIC to get them going?

I'm happy to help with debugging issues with getting CI to run the tests, but you could also just remove them and leave in the (low-risk) core change.

[arulagarwal]

Thanks for the review @marcprux! You were right — I re-enabled the three tests with an isRobolectric skip guard (matching the pattern used in CanvasTests, AnimationTests, etc.).

The issue is that Bundle.module colorset decoding falls back to gray (8E8E93) under Robolectric — a pre-existing runner limitation, not a problem with the parser. I confirmed this locally: without the guard all three fail (04F188 != 8E8E93), and with the guard they skip cleanly (92 tests, 0 failures, 5 skipped — up from 2 skipped before).

The tests will now actually run on CI's Android emulator where they should pass. Pushed in 8675983.

[marcprux]

Great, thanks for making the updates to the tests!