Name the workspace in the sync problem card when it is not the one in view

[joepio]

Requested by Joep · project thread

Before: viewing the Ontola drive, the Sync page showed "This server does not have this workspace" with "Drive atomic:LoASJ... is not enrolled for sync on this node". That is a different drive than the one in view, shown as a raw id, and "Turn off server sync" would have switched the viewed drive instead.

After: when the problem belongs to another workspace, the card says "This server does not have “<title>”" (or "another workspace on this device" if its name cannot be loaded), says it is not the workspace you are viewing, and only offers "Connect a device". The raw server message stays as the quoted detail. Problems with the viewed workspace read as before.

The Sync page builds this card from parked changes of any workspace on the device, not only the viewed one. The workspace is read from the server message (atomic: and did:ad: spellings treated alike) or from the parked change itself (store.driveOfSubject), and its title is loaded in SyncRoute.

How: syncProblem.ts gets driveOf and driveTitle inputs and an otherDrive field; unit tests cover the viewed drive, another drive with and without a title, a did:ad: spelling, and a drive found from the entry. Typecheck, lint and pnpm clean-translations done (three new msgids per catalog, nothing removed). Screenshots of the card are shared in the project thread, not in the repo.

Also in this PR (commit 2dcde14): the e2e spec sync.spec.ts "offline edits sync to server when connection is restored" failed in CI with the browser error "Save is still queued; the server has not acknowledged it." That error came from the debounced scheduled save reporting a queued offline edit through Store.notifyError, although a queued edit is a normal state that getSaveState already shows. The queued case now throws a typed SaveQueuedError, and only the scheduled-save path (SaveStatusCoordinator.createScheduler) ignores it. Explicit resource.save() callers still get the throw exactly as before; the wider question of how save() reports a commit that the outbox is still retrying is not touched here.

The host name in the card is still the node the app is connected to (node1.atomicserver.eu); that changes with the atomic.place node hostname cutover, not with this PR.

---

Generated by Claude Code

🤖 Generated with Claude Code

https://claude.ai/code/session_01FG3tCqQCD8TqAEhJ1Q7hmg

[joepio]

CI on b562afe stopped in the lib integration stage: upload-roundtrip.integration.test.ts and hosted-mcp.integration.test.ts (the latter with TypeError: fetch failed), so no e2e ran. Neither touches this diff, which only changes the sync problem card (syncProblem.ts, SyncRoute.tsx, a Store.driveOfSubject helper and the .po files). Same failure on develop runs 5208 and 5211, with "[WS] Connection failed" early in the log: the root cause was found in #2216 (Node's WebSocket never reconnects after a refused first connect). I ported that change into this branch (b1f0c8d, identical to #2216, no-ops once it reaches develop) and am dispatching a fresh run on the new head.

---

Generated by Claude Code

[joepio]

Complexity review after merge (+230/-14, patches only). Worth a small follow-up, not urgent.

1. syncProblem.ts: the fromMessage branch repeats the whole not-hosted problem object (key, cause, reported, ...) from the viewed-workspace branch right below it, differing only in title, body and actions. One builder would shrink it. The Drive (\S+) is not enrolled regex also duplicates the message format NOT_ENROLLED already matches, and otherDriveOf has a redundant ?? undefined.
2. SyncRoute.tsx (~1876-1900) calls describeSyncProblem twice per render, the first only to learn otherDrive so it can load the title. Have describeSyncProblem return the drive and let the caller supply the title lazily. driveTitle: () => ... also ignores its argument and closes over problemDriveName, which is a misleading API.
3. Scope: SaveQueuedError in resource.ts and save-status-coordinator.ts is unrelated to the problem card and would have been its own PR (the change itself is sensible).
4. Check that src/helpers/managed/refusedDrive.ts, which the four .po files now reference for "Disabled", exists on develop.

---

Generated by Claude Code