Fix the two bugs keeping main's CI red

[TheGreatAxios]

Summary

Main's CI has been red on two independent, deterministic bugs, reproduced identically across two separate CI runs (not a flake). This PR fixes one and diagnoses the other with a decomposition for follow-up.

Bug 1 (fixed) — Linux-only platform-detection test flake

apps/web/src/activatable-row.test.ts and apps/web/test/library-page-selection.test.tsx both had a "ctrl-click is not additive on Mac" test that passed locally on macOS but failed on ubuntu-latest.

Root cause: isMacPlatform() (apps/web/src/activatable-row.ts) reads navigator.platform and matches /mac|darwin/i. Under happy-dom's GlobalRegistrator, that value reflects the host OS, not a controlled test input — Darwin-flavored on a Mac, something else on Linux. So the "on Mac" test only exercised the Mac branch by accident of where it ran.

Fix: both tests now stub navigator.platform to the value they mean to exercise (mirroring the existing navigator.clipboard stub already used in library-page-selection.test.tsx), and activatable-row.test.ts gained an explicit non-Mac case so both branches of isAdditiveSelectClick are asserted deterministically regardless of host OS. No production code changed — isMacPlatform's behavior was already correct; the seam (navigator.platform itself) was injectable via Object.defineProperty, so no new seam was needed.

Verified: cd apps/web && bun run build && bun test ./src ./test → 775 pass, 0 fail. bun run lint from repo root → 0 errors (only pre-existing, unrelated warnings).

Bug 2 (not fixed in this box) — reuseExisting chat dedup

scripts/e2e/chat.test.ts:874 — "re-creating an existing agent chat reuses it" — expects reopening with reuseExisting: true to return the original chat's id (200), but CI reports a freshly-created id instead.

I traced the reuse path in packages/chat/src/routes.ts (findExistingAgentChat, sameAgent) and packages/chat/src/platform-adapter.ts (resolveDefinitionAssetId, resolveAuthoredProjectedDefinition from the CL-6452 origin-column work) end to end. On paper the direct-equality match (storedDefinitionId === definitionId, both from the same echoDefinitionId() helper) should hold and the reuse should succeed — I could not find a static defect in this path within the timebox, and didn't have time left to boot the full hub+sidecar e2e stack locally to get a live repro (Postgres was available locally, but the ports already in LISTEN state plus install/boot time made a safe repro too risky against the box).

Decomposition for the next lane:

1. Boot the e2e stack locally (DATABASE_URL=postgres://localhost:5432/<e2e db> bun test scripts/e2e/chat.test.ts) and add a debug log at findExistingAgentChat's match/no-match branch to see which side fails live.
2. If matches.length === 0: instrument sameAgent to log storedDefinitionId, definitionId, and both resolved assetIds — confirm whether echoDefinitionId() really returns a stable id across the two calls in the test (I could not rule out a subtle non-determinism in listInvitableDefinitions's ordering when the CL-6451 "second invite" test runs first in the same tenant).
3. If matches.length > 0 but the wrong row wins: check getWorkbenchTenancy and the createdAt fallback sort in findExistingAgentChat.
4. Once the live failure point is identified, fix forward from there — the e2e assertion itself is correct per the ticket and should not be weakened.

Test plan

• cd apps/web && bun run build && bun test ./src ./test — 775 pass, 0 fail
• bun run lint from repo root — 0 errors
• Bug 2 (scripts/e2e/chat.test.ts) — not fixed; needs a live e2e repro per the decomposition above
• Full e2e suite — not run in this box (stack boot risked exceeding the timebox)

Do not merge — bug 2 is still open; a peer reviewer should decide whether to merge bug 1 alone or wait for both.