fix(studio): Validity panel reports the loaded model, not a vacuous green

[w1ne]

The defect (KC-06)

Open a saved project with 2 parts and 1 revolute joint on app.kernelcad.com. The Validity tab renders:

solved · 0 parts · 0 joints · 0 diagnostics

…while the Scene tab lists both parts and the status bar reads "2 bodies". A green verdict computed over an empty set — worse than no panel, because it tells the user their mechanism validated when nothing was checked.

Root cause — two independent defects, both in src/studio/**

My initial hypothesis (the joint-primitive vs mate split) was wrong for the counts. It was right for the Joints tab.

1. The counts were literally hardcoded. src/studio/adapters/reviewToValidity.ts:61-62 on develop:

partCount: 0,
jointCount: 0,

Every model reported 0/0 — a .mate()-based model too. The file described itself as a "conservative Phase 1.1 adapter"; the deeper payload it was waiting for had already landed. src/agent/review/reviewPipeline.ts:262-267 returns validator: { status, partCount, jointCount } on both branches, but Studio's ScriptReviewSummary never declared the field, so the adapter never read it.

2. The green was fabricated. GeometryContext.tsx:988 (hosted path) and vite.config.ts:630:

const hostedReview = payload.review ?? { ok: true, diagnostics: [] };

deriveStatus reads if (review.ok) return 'solved'. So a placeholder no validator ever touched rendered as a pass.

3. Joints tab — this one is the joint/mate split. extractJointSnapshots read only metadata.mates, and __buildMateMetadata() returns undefined when mates.length === 0. Joint primitives capture as their own assemblyJoint records, with poses on the solvedAssembly record — reachable all along.

The change

Counts prefer the server's validator block and fall back to counting the loaded model's feature records. reviewWasValidated() derives provenance instead of trusting a flag a server could forget to set. When a review did not actually run, the chip reads not run (grey) with an explanatory notice — and only the passing verdict is suppressed; a real error/warning still reports as itself, covered by its own test. Joint primitives now produce joint snapshots, so the Joints tab populates.

Deliberately scoped to src/studio/**. Adding a 'not run' member to ValidatorStatus would have rippled through exhaustive switches across modeling and collided with concurrent work, so StudioValidity carries it Studio-side.

Verification

• tsc --noEmit clean; eslint clean on all 9 changed files.
• npx vitest run src/studio → 99 files, 654 tests, all passing (re-run independently in a checkout with generated assets).
• Negative controls — three separate sabotages, each restored:

Reverted	Result
counts back to 0, 0	5 fail — expected +0 to be 2, expected +0 to be 5
reviewWasValidated → return true	3 fail — incl. expected 'solved' to be 'not run'
joint-primitive block removed	1 fail — expected [] to have length 1

I independently re-ran the second one — the one that guards the actual reported symptom — and reproduced expected 'solved' to be 'not run' exactly.

tests/ failures in a fresh worktree are all environmental (missing gitignored assets/parts/, unbuilt dist/cli, kernelcad not on PATH, the known lightningcss.darwin-arm64.node); none import src/studio.

Two things for reviewer judgement

1. One existing test was updated deliberately: ValidityTab.test.tsx's makeValidity helper now sets validated: true, since a hand-built validator result stands for a validation that ran. Without it, every existing green-chip assertion would read not run.
2. The upstream half is not fixed here. The hosted mesh path ships responses with no review block, and the live=1 short-circuit is used for session-backed initial load. So on hosted load the panel will honestly read "not run" until the user presses Validate. If a saved project is meant to arrive already validated, that fix belongs on the server/review side — this PR stops the lie rather than papering over it.