🦄feat(web,desktop): check a material setup against its export

[polynaut]

A DazToHue material slot claims Daz surfaces by plain text, and so does every
texture baker layer. Change the scene — swap a graft out, drop an outfit — and
those claims keep naming surfaces that no longer exist: measured on DazToHue
2.5, a baker in that state finishes normally and bakes nothing, and Houdini
reports neither half. Nothing in the pipeline could see it.

Where the answer was

The .dth the HDA imports already carries a Materials list — one entry per
Daz surface, with the asset that owns it, the Daz content type and every
channel's texture path. Measured on a real export (LaraCroft_G81, DTH 2.0.2):
Material Name is verbatim the surface a slot claims — 26 of 26 exact matches
against that character's own scanned .hiplc. So the new Export check tab
needs no hython, opens no .hip and writes nothing; its two inputs are the
stored scan and a JSON file the studio itself wrote.

It reports claims the export does not back, baker layer groups it does not
back, and what a setup built from that export alone would look like — grouped
by the Daz content type, which is vendor-authored, so no heuristic is involved
(the eye stack is the one name match, and is marked as such).

• Unclaimed surfaces are grouped by content type and never flagged: a "naked"
  variant node is supposed to leave its wardrobe unclaimed.
• A project importing several scenes is refused rather than guessed at — the
  scan records imports per project, not per node.
• A texture-derived proposal is partial by construction; a baker built from a
  constant cannot be read out of an export. Said in the tab, not implied away.

The scan now records baker layer groups (bakerGroups) — it already computed
them and threw them away. SCAN_ANSWER_VERSION → 7 so existing entries re-earn
their verdict instead of answering the new question with [].

Not verified

The tab has never rendered against real data — the 6 new smoke specs drive the
real SPA end-to-end but against the fake native layer. The Python change is
unexercised for the same reason the rest of material_utils is (no harness; it
only runs inside hython). bakerGroups stays empty until the first rescan.

The three most likely to be wrong, in the order I would bet on them: the
baker-groups row (the only unexercised path — if it reads none on a project
with 6 bakers after the rescan, that is the bug); the proposal's slot/baker
naming and where the eye stack lands (judgement calls made from two projects);
and the unclaimed list reading as alarming on a "naked" variant, where it is
correct and the fix would be presentational.

Generation — the write half — is #851, which carries the design and the one
measurement it is blocked on.

Test plan

1. Open a character with a linked Houdini project → Utils → Export check.
   The first open re-runs the background scan (version bump), so give it a
   moment before the baker-groups row means anything.
2. On LaraCroft_G81 it should name the five GP* claims left behind by the
   Golden Palace removal and the metal1 / metal_1 mismatch — and say
   whether the skin bakers' layers still carry the GP groups too.
3. Toggle One clothing slot / One slot per garment and check the
   proposal against what you would have built by hand.
4. A character that has never been exported should say to run a DTH Export
   once, not show an empty setup.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JHYR4PVb5KgaknwGSmL6wH

[github-actions]

🔍 Site preview deployed

Preview (this PR)	https://pr-850.dth-character-studio.pages.dev
Guide	https://pr-850.dth-character-studio.pages.dev/guide/
Exactly this commit	https://fef5d8d9.dth-character-studio.pages.dev

Redeploys on every push to this PR. Production stays on GitHub Pages.