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 does not discover that filename. 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. Its current generalized *.browser.spec.ts discovery contract is the correct owner-side remedy and must be inherited/reconciled non-destructively before #151 can claim browser execution.

The earlier review observation that programmatic .focus() might not exercise :focus-visible is already addressed in #151's active branch: the committed forced-colors journey now uses keyboard-driven Tab focus. That observation is therefore historical/resolved, not an additional live defect. It does not become passing browser evidence until the separate discovery defect is fixed and the keyboard-driven journey actually executes on the exact current head.

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 keyboard-driven forced-colors spec for real on Chromium, Firefox and WebKit and repair any reproduced behavior 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.

[seonghobae]

Owner-boundary correction for the current accessibility lane:

• PR fix(accessibility): preserve forced-colors state cues #151 exact head is now eb3618c. It removes the competing browser-config edit and restores the keyboard-driven forced-colors journey.
• PR test(input): add multilingual browser input baseline #380 remains the sole owner of tests/browser/playwright.config.ts discovery; its current head a437ea7 has the generalized .browser.spec.ts matcher.
• The earlier 3-test browser result was run with a temporary config in a detached worktree and is not current fix(accessibility): preserve forced-colors state cues #151 browser evidence. Exact-head TypeScript validation passes; browser evidence remains pending the owner-lane reconciliation and rerun.