fix: workspace/dashboard persistence follow-ups — star→tile (#299), corrupt-aggregate surface (#300), dashboard filter persistence (#303)

[BorisTyshkevich]

What & why

Three workspace/dashboard persistence follow-ups from the #287/#280 refactor, in one PR (three commits).

Part of #299 — Workbench star → Dashboard tile membership. Since dashboard.tiles[] became canonical Dashboard membership (#280/#287), the Workbench star only flipped spec.favorite and never added/removed a tile, so favoriting a query had no effect on /sql/dashboard. toggleFavorite now reflects the flip onto tile membership in the same atomic commit via a new pure toggleTileMembership (src/dashboard/application/tile-membership.ts). The role gate mirrors the legacy-migration precedent — only panel-role queries become tiles; a favorited filter/setup-role query stays favorite-only. Unfavoriting removes every tile referencing the query and scrubs those tile ids from filter targets. spec.favorite stays the star's visual state — the documented dual-write retirement is deferred (so this is Part of, not Closes).

Closes #300 — surface a corrupt-but-present aggregate on boot. WorkspaceRepository gains loadCurrentResult(), distinguishing empty / ok / corrupt (with codec diagnostics) instead of collapsing "no record" and "unreadable record" both to null — which previously let boot silently continue on the legacy projection and orphan the corrupt record on the next CRUD commit, with no user-visible error. Boot now shows a toast with a Reset workspace action that clears the unreadable record and rebuilds a fresh aggregate from current local state. flashToast gained an optional, non-auto-dismissing action button. (Both the OAuth boot and the basic-auth connect path go through loadWorkspaceOnBoot, so both get the surface.)

Closes #303 — Dashboard filter values persist across reload. Regression from the #280 dashboard rewrite: the isolated viewer session initialized every filter purely from def.defaultValue/defaultActive and persisted nothing, so a committed filter value reset on reload (the Workbench var-strip was unaffected). Filter runtime value/active now persist to an isolated per-dashboard key (asb:dashFilters, dashboardId → filterId → {value,active}) — deliberately separate from the Workbench's asb:varValues/asb:filterActive (Option B) — and are seeded back on load. Read/write/merge is a pure dashboard/model store behind the existing loadJSON/saveJSON seam, so the viewer session stays AppState/storage-free (check:arch clean). Opening a dashboard never persists its defaults — only genuine committed changes write.

New inbox issue #303 was filed with the root-cause analysis. Roadmap #68's follow-ups note reconciled.

Verification

• npm test: 3485 passed (140 files); new pure modules 100/100/100/100.
• npx tsc --noEmit, npm run check:arch, npm run build: all clean.
• npm run test:e2e (chromium + webkit): 90 passed.
• /code-review (high): one real finding — the Dashboard filter values are not persisted across reload (regression from #280 rewrite) #303 persist effect wrote filter defaults to storage on first open (contradicting intent, freezing defaults against later Spec edits); fixed (seed the persist signature from the session's initial filter state) with a regression test.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable)
• Tests added/updated in the same change as the code
• npm run build succeeds (single-file dist/sql.html)
• Layers kept honest: pure logic in src/dashboard/model + src/dashboard/application, DOM in src/ui/, storage behind the injected seam
• No new runtime dependency
• README / CHANGELOG.md ([Unreleased]) updated
• Reconciled affected tracked work (roadmap Roadmap to 1.0.0 #68, issue bodies)

🤖 Generated with Claude Code

https://claude.ai/code/session_01GLMprUnwnz4oaz3cnLRKcz