Single-source the design palette between apps/web and apps/mobile

[toruiwasa]

Raised by the review of PR #110 (Task 9 / #12).

Field	Contents
Goal	The brand palette has one source of truth, so a colour changed for web cannot silently leave mobile on the old value.
Context	apps/mobile/src/constants/colors.ts was hand-derived from the --pt-* custom properties in apps/web/src/styles.css, and its file header says so. Every copied token matches byte-for-byte today. Nothing links them — no shared module, no test — so the drift is unguarded and silent: web changes, mobile still builds and still passes. This is the cost CLAUDE.md > Key Principles puts in packages/ to avoid. The review ranked it cleanup rather than a defect precisely because the fix is a design task, not a drop-in import, which is why it is filed instead of fixed in PR #110.
Scope	Decide where the tokens live and how each client consumes them. Web reads them as CSS custom properties and additionally carries a dark variant that mobile deliberately omits (REQ-17 Phase 1 specifies no dark palette), so a plain import does not work in both directions — this needs either a generation step from one source into styles.css + a TS object, or a shared TS module that styles.css is generated from. Open decision: which direction generates which, and whether the dark variant lives in the same source with mobile ignoring it.
Test boundary	A test that fails when the two palettes disagree is the actual deliverable — whatever the mechanism, the drift must stop being silent. No rendering tests.
Done when	Changing a brand colour in one place changes it for both clients, and a deliberate divergence fails a test rather than passing unnoticed.
Branch	refactor/shared-design-tokens
Dependency	none
Risk	LOW — no runtime behaviour changes if the generated values match the current ones; the risk is churn in styles.css, which is well covered by the existing web suite.