fix(#244): restore role-aware initial result views for saved and shared queries

[BorisTyshkevich]

What & why

Opening a Filter-role saved query from the Library, or via a share link/OAuth handoff, previously did not reliably start in the Filter preview:

• Library-row activation (src/ui/saved-history.js): a Filter-role query with SQL restored whichever result view (Table/JSON/Panel) was already active, and could be overridden by a dormant persisted spec.view/Panel config. A Filter-role entry whose SQL can't auto-run (empty/DDL — reachable via an import or legacy localStorage entry that bypassed filterSqlDiagnostics) fell through to no view change at all — a real gap surfaced independently by 4 of 8 code-review finder angles during this PR's own review.
• Share-link / OAuth-handoff bootstrap (src/main.js): resultView was only ever restored for a queryless Panel link (if (panel && panel.cfg) { if (!shared.sql) ... }). Any SQL-bearing shared Filter query, or a SQL-bearing shared Panel query with a persisted spec.view, always landed on the default Table view regardless of role or persisted view.

Both call sites now resolve the same precedence via one shared pure helper (rolePreviewView in src/core/result-choice.js):

role-owned transient preview (Filter) -> persisted spec.view -> queryless-Panel/default fallback

The Filter preview stays transient (no spec.view: "filter" is ever persisted), dormant Panel state is never touched, and ordinary reruns after a query is open continue to preserve the user's current Table/JSON/Filter selection.

Closes #244. Folds in #249 (closed as a duplicate) — that issue's narrower repro (empty-SQL Filter query) and the broader share-link restoration gap it pointed at are both covered here with one helper instead of two independent implementations that could diverge.

Verification

• npm test: 2761/2761 passing, src/core/result-choice.js and src/main.js at 100/100/100/100, src/ui/saved-history.js above the branches floor.
• Live-verified against a real ClickHouse demo cluster (otel):
  • Library-row activation for an auto-runnable Filter query, starting from Table/JSON/Panel views.
  • A non-auto-runnable Filter-role entry (injected via localStorage to simulate an unvalidated import) opening the Filter drawer instead of doing nothing.
  • The full OAuth sign-in round-trip restoring a Filter-role share link directly into the Filter preview.
• /code-review (high effort, 8 finder angles + verify pass) run on the initial Library-only diff; the confirmed finding was fixed in this same PR before opening it, and the resulting broader share-link gap was triaged into this issue's scope per user direction rather than filed separately.

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/core/, network in src/net/ (injected fetch), DOM in src/ui/
• No new runtime dependency
• CHANGELOG.md ([Unreleased]) updated
• Reconciled affected tracked work — issue Restore role-aware initial result views when opening saved or shared queries #244 body/title updated to reflect the broadened scope; src/main.js:92 share-link restore has the same Filter-role/persisted-view precedence bug as #244 #249 closed as duplicate; not tracked on roadmap Roadmap to 1.0.0 #68 (bug fix on already-shipped Dashboard: multi-filter option bundles, shared preview, and role-aware result selector #160/D6 work, not a new phase item)

🤖 Generated with Claude Code

https://claude.ai/code/session_01PQbDSVDUTUk1bA8891cX9y