Consolidate XpColor into bracket-color

[mors119]

Summary

Unify the duplicated XpColor implementations in bracket-color and bracket-rex so the workspace uses a single canonical XpColor type.

Problem to solve

XpColor currently exists in both bracket-color and bracket-rex, even though both types represent the same RexPaint-style RGB color and have nearly identical behavior.

This creates a few problems:

• it is unclear which XpColor should be treated as the canonical public type
• facade and prelude re-exports become harder to manage cleanly
• re-exporting RexPaint-related APIs can introduce ambiguity or naming conflicts
• contributors have to reason about two nearly identical implementations in different crates

This affects both maintainers working on crate boundaries and downstream users trying to understand which RexPaint color type they should use.

Proposed solution

Choose one canonical XpColor type for the workspace and update the other crate to use it instead of maintaining a duplicate implementation.

The most natural direction appears to be:

• keep XpColor in bracket-color as the shared color representation
• update bracket-rex to use that shared XpColor instead of defining its own copy
• adjust any conversions, imports, and public exports accordingly
• keep RexPaint file structures such as XpFile, XpLayer, and XpCell in bracket-rex, but have them reference the shared XpColor

This would reduce duplication and make future RexPaint-related exports much easier to reason about.

Alternatives considered

Keep both XpColor definitions as-is.
This avoids short-term refactoring, but preserves the current confusion and duplication.

Add more selective re-exports around the existing split.
This can work around the symptoms in some places, but does not resolve the underlying type duplication.

Introduce a brand new shared color wrapper elsewhere.
This is possible, but likely adds more migration cost than necessary when an equivalent type already exists.

Additional context

The current duplication becomes especially visible when working on RexPaint-related re-exports, because both bracket-color and bracket-rex can surface a type named XpColor.

A unified XpColor would simplify the public API and make crate responsibilities clearer:

• bracket-color owns shared color types
• bracket-rex owns RexPaint file structures and I/O
• higher-level facades can re-export these APIs with less ambiguity