feat: base assistant detail page (#20)

[martinydeAI]

Links to issues

• Refs #20 — Assistant detail page
  (delivers the name + description + tags + model + framework
  half; remaining scope deferred — see the AI specificities block).
• Refs #16.
• Depends on PR #67
  (base Assistant entity), which depends on
  PR #59 (Doctrine +
  PHPUnit).

Description

Adds a base assistant detail page at GET /assistant/{id} plus the
fixture baseline the rest of the integration suite now reads from.

Application code

• App\Controller\AssistantController::show — single action, route
  app_assistant_show. Symfony's MapEntity converter resolves
  {id} → Assistant and 404s on a missing row.
• templates/assistant/show.html.twig — extends base.html.twig,
  uses the existing Eyebrow / Box components, and reads from the
  assistant.detail.* translation keys added under the existing
  security pattern in translations/messages.da.yaml.
• App\Controller\FrontpageController + templates/frontpage/index.html.twig
  — rail and stats blocks now consume real assistant data so the
  frontpage reflects the seeded catalogue (rail shows the five
  newest entries id-DESC; stats show total assistants and distinct
  language-model count).

Fixtures

• App\DataFixtures\AssistantFixtures seeds 21 deterministic
  assistants: six hand-written rows (five authentic prototype
  entries plus the tagless Uden kategorier edge-case row used by
  the controller's empty-tags branch) and fifteen generated from a
  fixed grid of seven topics × ten kommuner × five language models.
  No randomness — same input every run.
• tests/bootstrap_integration.php now loads AssistantFixtures
  alongside UserFixtures once per suite. DAMA's PHPUnit extension
  wraps each test in a transaction that rolls back at tearDown, so
  per-test mutations stay isolated while the baseline survives the
  whole run.

Tests

• tests/Unit/DataFixtures/AssistantFixturesTest.php — pure
  TestCase mirroring UserFixturesTest; mocks ObjectManager,
  captures persist() calls, asserts the 6 + 15 layout, the
  tagless row's empty tags, unique (title, description)
  signatures for the generated entries, the full five-model
  rotation, and determinism across two load() invocations.
• tests/Integration/Repository/AssistantRepositoryTest.php —
  resolves the repo from the container and round-trips a
  persist / find.
• tests/Integration/Controller/AssistantControllerTest.php —
  three cases driven entirely off the fixture baseline (no ad-hoc
  new Assistant): happy path with tags
  (Borgerservice-vejviser), empty-tags branch via the
  Uden kategorier row, and 404 for an unknown id.
• tests/Integration/Controller/FrontpageControllerTest.php —
  fixture-only. Derives the expected top-5 rail entries via
  AssistantRepository::findBy([], ['id' => 'DESC'], 5) so the
  assertions stay correct if the seed grows, and pins the stats
  <dl> to the fixture totals (21 / 5).

Screenshot of the result

(Optional — screenshot the detail page and the updated rail/stats
block if useful for the reviewer.)

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.

If your code does not pass all the requirements on the checklist you have to add a comment explaining why this change
should be exempt from the list.

Additional comments or questions

do-not-merge is intentional — this PR sits on top of #67 (which
sits on top of #59). Per the CLAUDE.md do-not-merge rule the
blocker is the dependency chain; remove the label once both
ancestors land.

---

Details - AI specificities

Goal and motivation

• Assistant details page #20 wants name, description, organisation/author, tags, model,
  parameters, system prompt, and an export entry point on a
  per-assistant detail page. The base entity from feat: add base Assistant entity (#14) #67 only carries
  six fields, so this PR delivers the half that has data today and
  defers the rest to follow-ups that each unblock a chunk.
• Fixtures were folded into this PR because the frontpage rail and
  stats blocks needed real catalogue data to render meaningfully,
  and the integration tests for both controllers wanted a shared,
  deterministic baseline rather than ad-hoc new Assistant
  constructions in every setUp().

Scope

• Controller + template for the detail page.
• Frontpage controller and template, now reading from the
  repository.
• AssistantFixtures seed (6 + 15 = 21 entries) with one tagless
  edge-case row.
• tests/bootstrap_integration.php loads the assistant baseline
  alongside UserFixtures.
• One unit test per new code surface (AssistantFixturesTest) and
  two integration tests refactored to read from the baseline
  (AssistantControllerTest, FrontpageControllerTest), plus
  AssistantRepositoryTest for the repository round-trip.

Non-goals / deferred

• Export entry point → #22.
• System prompt + parameters → #14
  (richer scope).
• Organisation / author display → ADR 005 +
  #65.
• Back-link to a real catalogue → #15;
  currently links back to the frontpage as a placeholder.
• Empty-state branch of the rail. The fixture baseline is always
  loaded, so the no-assistants case is no longer reachable in the
  integration suite. If empty-state coverage matters later it
  belongs as a unit test of the rail template, not at the
  controller-HTTP layer.

Conventions applied

• Fixture file pattern mirrors UserFixtures (registered as a
  service, loaded by tests/bootstrap_integration.php once per
  suite, isolated per-test by DAMA's enable_static_connection
  configuration in config/packages/dama_doctrine_test_bundle.yaml).
• Unit-test pattern mirrors tests/Unit/DataFixtures/UserFixturesTest.php
  (pure TestCase, mocked ObjectManager, captures persist
  callbacks).
• Integration controller tests are fixture-only — no
  new Assistant(...) / $em->persist / $em->flush. Test data
  is found by title (findOneBy(['title' => …])) so a fixture
  reshuffle that preserves titles doesn't break the tests.

Areas needing scrutiny

• The "newest first" rail assertion in FrontpageControllerTest
  derives the expected ordering from the same query the controller
  uses (findBy([], ['id' => 'DESC'], 5)). That keeps it
  resilient to fixture growth but means the test won't catch a
  regression where the controller silently changes the order — a
  later snapshot-style test could add that.
• Stats <dl> is keyed to 21 (total) and 5 (distinct language
  models). Reseeding AssistantFixtures requires updating this
  assertion; the test's comment names the five LMs to make the
  brittleness explicit.

Related

• ADR 005 / #65 for
  the Organization entity that the detail page will eventually
  surface (author / domain).

[tuj]

Rename kommune to municipality