feat(ui): every export-target refusal reads as prose

[JArmandoAnaya]

Summary

The frontend half of the export-targets closeout. Two refusal codes the export dialog could receive had no sentence in the shared vocabulary and fell through to the server's raw message, and the three family headings the target picker and the recipe editor print were kept in two hand-written maps over the same wire enum. Together with the companion backend pull request (feat/targets-closeout-backend) this completes the epic.

What changed

Every export-target refusal reads as prose. EXPORT_TARGET_CONFLICT and INVALID_EXPORT_TARGET are the two 500s a misdeclared export plugin raises: two installed plugins claiming one target name, and a plugin declaring a target whose geometries its own exporter never writes. Neither is a rule the person broke, so frontend/ui-core/src/data/refusals.ts now gives each a sentence that says where the problem is and what helps — remove one of the two plugins, or check the installed export plugins. Two forced-refusal tests in dataset.test.tsx drive each code through the export dialog and assert the prose renders while the code itself is absent from the DOM; both fail without the entries. The withheld-codes list in data/capabilities.test.ts names neither code, so it needed no change.

One table names the export-target families. ExportTargetSelect.tsx kept FAMILY_HEADINGS plus an OTHER_HEADING and RecipeEditor.tsx kept FAMILY_WORDS, two maps over the same server family string. They are now one exported EXPORT_TARGET_FAMILIES table with a heading (over a group, plural) and a word (beside one target) per row, and exportTargetFamily(family) resolves a family to its row with the last row as the catch-all. The select groups through it and the editor's targetSubtitle reads its word from it. The headings the docs quote under docs/content/ui.md are unchanged.

One user-visible wording changed: a family the build has no row for. The select already placed such a target under Other formats; the editor printed the raw wire string (some-new-family) beside it. Both now read the same catch-all row, so the editor says Other format for it. The three named families print exactly as before.

Found, not fixed

Nothing outside the two files named above was touched. The family string on ExportTargetOut is open on the wire (no enum in openapi.json), so the table's catch-all remains the only place an unknown family gets a name; a served family list would let both the select and the editor drop the hardcoded rows, but that is a wire change and not part of this closeout.

Test plan

$ pnpm --filter @visionset/ui-core exec vitest run src/screens/dataset.test.tsx src/screens/preprocessing.test.tsx
 Test Files  2 passed (2)
      Tests  72 passed (72)

The two new tests were proven to bite by stashing the refusals.ts entries:

     × renders EXPORT_TARGET_CONFLICT as prose 132ms
     × renders INVALID_EXPORT_TARGET as prose 109ms
      Tests  2 failed | 3 passed | 44 skipped (49)

$ pnpm -r build && pnpm -r test && pnpm -r lint
frontend/annotator test:  Test Files  37 passed (37)
frontend/annotator test:       Tests  1071 passed (1071)
frontend/ui-core test:  Test Files  63 passed (63)
frontend/ui-core test:       Tests  1393 passed (1393)
frontend/app test:  Test Files  1 passed (1)
frontend/app test:       Tests  11 passed (11)
lint exit=0

$ bash scripts/check.sh
  1 passed (29.7s)
All checks passed.
check.sh: PASSED  ran=python,frontend,generated,browser  skipped=docs

Closes #784