Play Framework

test(docviewer): cover /@docs routing and give the module a real unittest target (PF-164)

PF-163 — /@docs redirecting to itself forever for requests without an
accept-language header — shipped undetected because docviewer had no tests at
all, and could not have had the useful kind: app/ (controllers, helpers,
DocViewerPlugin) is compiled at runtime by ApplicationClassloader, so nothing in
it is reachable from a JUnit sourceset.

Two complementary layers, split along that constraint.

1. integration.DocViewerFunctionalTest — the layer that would actually have
   caught PF-163. The bug lived in the interaction of three things: the
   ControllersEnhancer turning a cross-action call into a redirect, reverse
   routing choosing a route for the args it is given, and prependRoute making
   later registrations win. Only a booted application exercises all three. The
   module is mounted into the integration fixture via a testapp/modules/docviewer
   marker file, and the suite walks redirect chains with a bounded hop count so a
   loop fails with a diagnostic instead of hanging.

   Verified to fail against the pre-PF-163 controller — reverting the fix turns
   4 of its 7 tests red with e.g.

     redirect chain from /@docs did not terminate within 5 hops
     (last: /@docs/home?docLang=) - /@docs is looping again, see PF-163

   while the three that should be insensitive to it (module mounted, the
   with-header path, French localisation) stay green — so the suite is specific
   to the defect rather than failing blanket.

   It also pins the fix's *shape*: acceptLanguageIsCarriedIntoTheRedirect guards
   the obvious alternative fix (deleting the shadowing /@docs/home route), which
   stops the loop but silently drops language auto-detection for that URL.

2. play.modules.docviewer.DocumentationGeneratorTest — docviewer's build.xml
   unittest target is no longer a no-op, so module-unittest (run at the end of
   ant unittest) exercises real tests. Scoped to src/, the only part ant
   compiles: getTitle/toHTML/stripBody, including the stripBody(toHTML(x))
   pairing every rendered page depends on.

Build wiring: Play.addModule puts a module's app/ on javaPath but not its lib/
jars on the classpath — that is the launcher's job — so play-docviewer.jar is
added via a new classpath.integration path, kept separate from classpath.test so
plain unit tests cannot accidentally depend on module classes. integration-test
now also depends on `modules` so the jar exists on a bare run from a clean tree.

CLAUDE.md documents the mounting pattern and both gotchas (module lib jars, and
the single shared Play instance across the integration suite).

Not covered: DocViewerPlugin.rawInvocation's /@docs/api Javadoc branch,
ProjectDocumentation, and the app/ helpers — all still runtime-compiled and
reachable only by adding more integration coverage.

`ant test` green from clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>