feat: ret datafølsomheds-kategorier og fejlbeskeder i delingsflowet

[martinydeAI]

Links to issues

Closes #223

Leantime tickets: 8211, 8219.

Description

Two problems user testing found in the share wizard.

8211 — data sensitivity. There was no option for material that holds no
personal data, so curators with purely factual sources had to overstate.
The topmost option also confused people because its copy was circular
("almindelige personoplysninger og ikke-følsomt indhold").

• New DataSensitivity::NoPersonal ("Ingen personoplysninger"), declared
  first so the scale runs least-sensitive downward.
• "Almindelige personoplysninger" now says what it covers — GDPR article 6,
  identifying but neither confidential nor sensitive.
• New example() accessor adds a third line to all four cards naming
  concrete documents, so the choice is made by recognition.
• No migration: data_sensitivity is a nullable STRING(32) with enumType.

8219 — the paste field. First-time curators could not see what the field
expected, and a rejection told them things like A Modelfile must contain a FROM instruction.

• The textarea carries a minimal OpenWebUI export as its placeholder.
• ValidAssistantConfigValidator no longer aggregates every adapter's
  schema errors. It states the file was rejected and names the accepted
  formats.
• The live check endpoint routes its errors through assistant_validation,
  which gains a Danish rendering of the Modelfile line for people who really
  are pasting one.

What counts as valid is unchanged; only the reporting is.

Screenshot of the result

Not included — the wizard sits behind authentication and I could not drive
the stateless-CSRF login from the sandbox. The radio cards now carry three
lines each and the textarea has a multi-line placeholder, so a reviewer
should look at the actual step for spacing.

Checklist

• My code is covered by test cases.
• My code passes our test (all our tests).
• My code passes our static analysis suite.
• My code passes our continuous integration process.

Markdown lint could not be run locally: itkdev/markdownlint's arm64 manifest
entry contains x86-64 binaries, so the container exits with exec format error
on aarch64. CI will cover it.

---

Details - AI specificities

Root cause of the unreadable errors. ValidAssistantConfigValidator
looped every registered adapter and raised one violation per error line. Since
only one format can be right, the other four always contributed noise — which
is why a near-valid OpenWebUI file got told about Ollama's FROM instruction.
The registry still decides validity; the loop only ever shaped the message.

Test changes (both approved in advance, no assertion weakened or skipped):

• DataSensitivityTest — testCasesReturnsAllThree → testCasesReturnsAllFour,
  new backing value pinned, new testExampleBuildsTranslationKeys. A docblock
  records that declaration order is contract, not incidental: it drives the
  radio-card order.
• ValidAssistantConfigValidatorTest — the two violation-shape tests now assert
  the exact statement + help pair rather than deriving expectations from the
  adapter error list. Asserting the exact pair is deliberate: it fails if the
  per-adapter dump is ever reintroduced. The passthrough translator stub is gone
  with the validator's translator dependency.

Colour choice. The new case maps to info (blue) on the detail-page pill
rather than green. Green already means "handled ordinary personal data
correctly", and collapsing both onto it would lose that step.

Known remaining gap. Opis JSON-schema errors still surface in English on
the live check endpoint — they carry interpolated {property}/{path} context,
so a keyword-level mapping would need revisiting on every library bump. Out of
scope here; the fixed adapter strings are translated.

Verification. task test — 691 tests, 2041 assertions, green (up one from
the new enum test). task test-coverage is 100% once
src/DataFixtures/LocalUserFixtures.php is excluded; that file is gitignored
and untracked, so it does not exist in CI. PHP CS Fixer, Twig CS Fixer, and
Prettier on the three changed YAML files all pass. bin/console lint:yaml translations is clean and debug:translation da shows all twelve
assistant.data_sensitivity.* keys defined with none missing.

Non-goals. The remaining Form-adjacent asks from the same round are not
here: a written guide to the export format (part of 8219's original wording)
would be a docs page, not a form change.