feat(app): add persistent project colour tags

[willem4130]

Summary

Cross-platform verification: all six jobs passed in the fork's existing CI workflow, on the exact PR commit and base. The upstream workflow still needs maintainer approval; details below.

Add personal project-colour preferences to the workspace header so multiple project sessions are easier to distinguish.

• Keep the existing deterministic automatic colour by default, with the stripe disabled.
• Offer ten named colours, Automatic to reset, and None for a neutral outlined dot without a stripe.
• Persist choices by full canonical project-folder identity, not session or final folder name. Extra sessions, app restarts, and same-name folders therefore behave consistently.
• Use a 10px accent dot and an optional 6px band beneath the header strip. The dark background, status colours, action controls, and native titlebar appearance are unchanged.
• Leave folderless Code/Chat views and the existing folder-opening action intact.

Implementation

• Rust owns native preference persistence and serializes read/merge/atomic-write updates across app windows. Invalid choices and malformed files are rejected; unrelated fields and other project preferences survive updates.
• Typed native command/event wrappers live in agent.ts. The store validates raw native payloads, listens before reading, rejects stale revisions, and releases listeners when the last subscriber leaves.
• Preference events are intentionally app-wide; agent events remain scoped to their own webview.
• Browser previews use separate localStorage keys per project, avoiding whole-map lost updates.
• The non-modal picker supports keyboard navigation, Escape, Tab, outside-click dismissal, focus restoration, long names, zoom, and viewport bounds.
• Rapid choices retain the latest pending selection instead of silently dropping clicks during an active save.
• Fix the Mac WebKit mouse-up interaction: automatic composer focusing no longer steals focus from clicked controls or open dialogs and dismisses the picker before its click runs. Regression tests mount the real App focus handler and picker together.

Startup budget

Rich Markdown rendering is deferred behind a bounded, escaped plain-text loading/error fallback, preserving the existing rich-renderer controls and contexts. A production-build regression checks the real manifest and chunk sizes. The tightened initial-JavaScript baseline is not loosened, and the build test launches Vite through Node directly rather than a Windows-incompatible pnpm shim.

No dependencies, session schema, credentials, permissions, or release configuration are changed.

Verification

Local verification on macOS with Node 22.17.0:

• pnpm --filter gg-app test: 557 tests passed across 70 files, with default parallel execution.
• pnpm --filter gg-app check: passed.
• pnpm --filter gg-app lint: passed.
• Prettier check of changed frontend files: passed.
• cargo test --locked --manifest-path gg-app/src-tauri/Cargo.toml: 82 tests passed.
• pnpm --filter gg-app build: passed, with all production JavaScript chunks below the unchanged 500,000-byte warning limit.
• node bench/size-gate.mjs --only frontend:initial: passed (526.8 KiB current vs 526.0 KiB baseline).

Packaged macOS testing used isolated demo projects and a separate profile, without real credentials or normal settings. Native mouse-event checks passed for all ten colours, None/Automatic, rapid clicks, stripe switching, persisted values, and same-project synchronization while another project's choice stayed independent. Those native checks exercised the picker/focus fixes before the final behavior-preserving bridge relocation; the final bridge's exact command payloads and app-wide event contract are covered by automated transport tests.

Native Windows/Linux colour-picker interactions have not been manually tested. Automated Windows installer build-and-launch verification passed in the fork CI run. This PR is ready for maintainer review; the upstream workflow approval/checks remain pending before merge.

CI status

Independent cross-platform verification passed: fork CI run 35306059427.

The unmodified existing workflow ran against head 2ab93a20f802eed7b91cd7c100d446a5b6ecca2e and base c533dde20271a73c2632bc4afb0ece71393a668a, matching this upstream PR exactly.

Job	macOS	Windows	Linux
Framework build, typechecks, tests and performance gates (Node 22)	Passed	Passed	Passed
App staging, bundled-sidecar smoke, frontend build/size gate/tests and Rust tests	Passed	Passed	Passed

The Windows app job also passed Packaged app smoke (MSI build + launch). All six jobs completed successfully, without workflow changes or weakened checks.

A temporary verification PR in the fork triggered this run; it is closed without merging and neither repository's main branch is modified.

The upstream CI run still requires maintainer approval (action_required) and has not started any jobs. The independent results are evidence, not a replacement for the upstream repository's own required checks. Please approve that workflow run when convenient. This PR is ready for review, but the upstream checks still need to run before merge.

[willem4130]

@KenKaiii This PR is now ready for your review. To reduce maintainer setup, I ran the unmodified existing CI workflow independently on the exact PR head and base: all six framework/app jobs passed across macOS, Windows and Linux, including the Windows MSI build-and-launch smoke check. Results: https://github.com/willem4130/gg-framework/actions/runs/35306059427 . Implementation details, regression coverage and local/native verification are in the PR description. The upstream workflow still needs maintainer approval before its own checks can run; the fork results do not bypass that gate. Thank you for taking a look.