fix(accessibility): preserve forced-colors toolbar and editor state cues

[seonghobae]

Stable product contract

This issue tracks Inkspan's forced-colors / Windows High Contrast accessibility boundary. Protected main is the only shipped implementation authority. Canonical Draft PR #151 / branch fix/forced-colors-accessibility is the existing source owner for this slice; its exact head, live protected base, ancestry, reviews, threads, workflows and mergeability are mutable and must be refetched immediately before any lifecycle action rather than copied into this issue as status truth.

Required behavior

Inkspan must preserve its editor/container boundaries, toolbar and collaboration chrome, grouping, keyboard focus, active/disabled states, authored links, code/pre/table boundaries, and collaboration cursor/label visibility under forced-colors: active using platform CSS system colors. Disabled controls must not rely on opacity alone. Authored links must retain a non-color affordance. Normal light/dark behavior outside the forced-colors media query must remain unchanged, and Inkspan must not disable user-agent forced-color adjustment merely to preserve authored presentation.

This remains standalone presentation/accessibility scope. It adds no persistence, transport, credentials, model use, authorization, tenancy, network/provider/room, durable-audit, or host-policy authority.

Test-first lineage

Canonical #151 records the behavioral lineage, including RED coverage for missing forced-colors state mappings and for a cascade-order defect where later equal-specificity screen rules could override forced-colors styles. Those predecessor generations establish causality only; their workflow/review evidence does not transfer after any branch or protected-base movement.

Browser-evidence correction

A committed Playwright spec is not execution evidence merely because repository CI is green. At the latest live inspection, #151's forced-colors spec exists at tests/browser/specs/forced-colors.browser.spec.ts, while the inherited desktop-engine selector in tests/browser/playwright.config.ts matches only clipboard/focus/print browser specs. The forced-colors spec is therefore structurally undiscovered on that source generation. Any issue/PR prose claiming that the real browser matrix already proves forced-colors behavior is superseded until an exact-current-head run shows the spec was actually discovered and executed.

Draft #380 is the existing dedicated writer for the shared browser harness/config boundary. Preserve single-writer ownership: do not race it by independently editing tests/browser/playwright.config.ts from #151. After the config and #151 source are reconciled, the browser lane must prove real discovery/execution on Chromium, Firefox and WebKit. A separate review observation that programmatic .focus() may not exercise :focus-visible reliably remains open until the newly discoverable test reproduces or disproves it with keyboard-realistic behavior.

Acceptance / integration boundary

Keep this issue open until the forced-colors behavior is protected-main integrated under then-live governance. Before any #151 lifecycle transition:

1. refetch the exact fix(accessibility): preserve forced-colors state cues #151 head, independently resolved protected-main base, ancestry/mergeability, changed paths and active writers;
2. refetch live rules/protection, formal reviews, unresolved threads, combined statuses and every applicable repository/central workflow/job with actual checkout SHA;
3. reconcile protected-main movement non-destructively; never force-push or destructively rebase;
4. inherit/reconcile the browser-discovery contract through the existing test(input): add multilingual browser input baseline #380 owner rather than creating a competing config writer;
5. run the forced-colors spec for real and address any reproduced focus-visible defect test-first;
6. regenerate exact-current-head/live-base CI, security/SAST, exact coverage, packed-package, browser/accessibility, Office and required central evidence;
7. obtain qualifying independent formal approval with zero unresolved threads and merge only an unchanged gate-clean exact head.

Pending, queued, skipped, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, wrong-checkout, synthetic-merge-only, undiscovered-test, or otherwise vacuous evidence is non-passing. Do not self-approve, weaken gates, transfer predecessor evidence, invent approval/evidence, bypass governance, create a competing style/browser-config writer, or represent active-PR behavior as shipped.