feat(ui): add first-session onboarding preview card to maintainer dashboard

[claytonlin1110]

Summary

• Adds OnboardingPreviewCard to the maintainer dashboard: on first visit, it auto-runs the existing settings-preview simulator (buildSettingsPreviewRequest, POST /v1/repos/:owner/:repo/settings-preview) against the repo's most recently cached pull request, so a maintainer sees "here's what Gittensory would have flagged" without manually filling out SurfacePreview's form.
• Real data is used where it exists (the PR's real title, and its linked-issue number scraped from the reviewability row's reason string, e.g. "linked issue #7"); everything the cached reviewability projection doesn't carry (author identity, labels, body) is filled from the same confirmed-miner representative scenario SurfacePreview already defaults to.
• Renders the result through PreviewResult (now exported from maintainer-panel.tsx) — the exact same decision/checklist/comment-preview UI SurfacePreview already uses — rather than inventing a new findings display. The settings-preview response has no discrete findings array; "flagged" here means decision.willComment / willLabel / willCheckRun.
• Dismissible via localStorage, reusing this codebase's established first-visit-card idiom (useLocalStorage, the same pattern app.index.tsx's OnboardingChecklist and notification-readiness-card.tsx already use) rather than inventing a new mechanism.
• Distinct from ActivationPreview (one-step maintainer activation / instant-value onboarding #701/feat(activation): one-step maintainer activation preview + advisory ramp (#701) #708, already merged in feat(ui): add maintainer activation preview card #3790): that card shows aggregate multi-PR evaluation stats from a dedicated /activation-preview endpoint with an activation CTA. This card shows one demo run's full policy decision (comment/label/check-run + trust checklist + sanitized comment text) from the settings-preview pipeline — complementary, not a re-implementation.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked a currently open issue this PR resolves — Closes feat(ui): install-preview 'what gittensory would have flagged' card (onboarding) #2217.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally (apps/** is Codecov-ignored — UI-only change — but shipped 5 new tests: flagged-findings-present, clean/skip verdict, no-recent-PRs empty state, API-error state, and dismiss-persists-and-skips-the-fetch-on-remount)
• npm run test:workers
• npm run build:mcp
• npm run ui:openapi:check
• npm run ui:openapi:settings-parity
• npm run ui:version-audit
• npm run docs:drift-check
• npm run manifest:drift-check
• npm run command-reference:check
• npm run db:migrations:check
• npm run db:schema-drift:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:test (138/138 passed across both UI workspaces)
• npm run ui:build
• npm audit --audit-level=moderate (0 vulnerabilities)

If any required check was skipped, explain why:

• npm run test:mcp-pack and npm run cf-typegen:check fail locally only due to a pre-existing Windows dev-machine spawnSync bare-command resolution gap (ENOENT for npm/wrangler without shell: true), unrelated to this diff — no packages/gittensory-mcp or wrangler.jsonc changes here.
• npm run engine-parity:drift-check fails locally only because it falls back to my local (stale) fork origin/main ref absent GITHUB_BASE_SHA, which real CI sets. No src/signals/**/packages/gittensory-engine/** files are touched.

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed — the demo run reuses the exact same public-safe settings-preview endpoint/sanitizer SurfacePreview already calls; no new data surface.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics. (The rendered comment preview is the same sanitized previewComment the existing simulator already produces and labels "sanitized".)
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. (N/A — no such changes; the card is gated behind the same maintainer-role check the rest of MaintainerPanel already enforces.)
• API/OpenAPI/MCP behavior is updated and tested where needed. (N/A — no new endpoint; reuses the existing settings-preview route.)
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks — it's a live POST against real cached PR data, with a tested loading/error/empty StateBoundary, not a static demo.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs. (No changelog edit in this PR.)

UI Evidence

State / title	Screenshot
Loaded state (flagged findings)	demo run against a real cached PR — would comment, label, and check-run
Empty state	no recent pull requests cached yet

Notes

• Placed at the top of MaintainerDashboardView (right after the refresh-meta row, before the metrics grid) so it reads as the first-session "hero" moment the issue describes, ahead of ActivationPreview/SurfacePreview.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-10 19:34:11 UTC}

3 files · 1 AI reviewer · no blockers · readiness 82/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a first-session onboarding card that auto-runs the existing settings-preview simulator against the repo's most recent cached PR and renders it through the already-existing `PreviewResult` component (now exported), reusing `buildSettingsPreviewRequest`/`useLocalStorage` patterns from `ActivationPreview`/`OnboardingChecklist`. The linked-issue scraping from the `reason` string and the localStorage dismiss flow are both tested, and the empty/error/loading states are wired through the existing `StateBoundary`. The main risk is `target`/`load` identity churn on every parent render potentially re-triggering the network call, which isn't covered by a test.

Nits — 2 non-blocking

• External size/complexity signals flag `OnboardingPreviewCard` at ~101 added lines with cyclomatic complexity ~11 and nesting depth 5 (JSX conditional/StateBoundary nesting) — consider extracting the header/dismiss button into a small subcomponent for readability.
• onboarding-preview-card.test.tsx: the dismiss/remount test relies on `render()` synchronously flushing hydration + load effects without `waitFor`, mirroring an assumption noted for `ActivationPreview` — a `waitFor` guard would make this more robust to timing changes in `useLocalStorage`.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2217
Related work	⚠️ 1 scoped overlap	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 461 registered-repo PR(s), 318 merged, 102 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	claytonlin1110; Gittensor profile; 461 PR(s), 102 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: claytonlin1110
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, TypeScript, Rust
• Official Gittensor activity: 461 PR(s), 102 issue(s).
• Related work: Titles/paths share 3 meaningful terms. (issue #642, issue #2013)

Contributor next steps

• Review top overlaps.
• Add a concise scope and risk note.
• Check active issues and PRs before submitting.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop			—
/	mobile			—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.