verifyExampleSelectionGuide asserts a stale release literal (0.4.0) and is red on the Epic base

[GionaGranchelli]

verifyExampleSelectionGuide fails on the current Epic base, which makes a full-closure workflow_dispatch RC impossible to turn green. Found while certifying 0.7.1e (#420), where it appeared as an RC failure that had nothing to do with that slice.

Evidence

• build-logic/src/main/kotlin/dev/tramai/build/docs/RootDocGuardVerifiers.kt:579 requires the ### Kotlin Spring Boot Example section of examples/README.md to contain the literal '0.4.0'.
• That section now says "released TramAI 0.6.0 dependencies" and contains zero occurrences of 0.4.0.
• The guard is red on 99b2b638 (current Epic head) exactly as on any branch: the file it reads is identical there (git show 99b2b638:examples/README.md — same 0.6.0 wording, 0 occurrences of 0.4.0). Nothing in the candidate (feat(0.7.1e): control-plane authority contract — public ports + HTTP concurrency adapter #420) touches examples/README.md or the guard.
• ./gradlew verifyExampleSelectionGuide fails deterministically and locally, independent of tramaiVersion.

Why it was invisible

The Sovereign Runtime RC selects its task by trigger:

• pull_request → verifySovereignRuntimePullRequest (sovereign release-chain proof, no repository test/check graph)
• workflow_dispatch → verifySovereignRuntimeClosure --rerun-tasks (the FULL closure, which does include the docs guards)

So every green PR-triggered RC run — including the ones certifying 0.7.1d and the migration-history fix — never executed this guard. It only appears under explicit release certification, which is exactly when it must not be broken.

Proposed fix (one line, either side)

The stale side is the guard's literal: the doc correctly describes the currently released version. Two options, both tiny:

1. Update the guard to expect the current released version, ideally derived from the release line rather than a new hardcoded literal — otherwise this recurs at the next release cut.
2. Drop the literal assertion and assert a version shape instead, since the guard's real purpose is that the section names released coordinates rather than any specific number.

Either way the fix belongs in its own Epic-base PR, and the same "guard asserts a stale release literal" smell is worth one sweep of the other docs guards for other pinned version strings.