Stop documenting the pre-rename fallback for users

Exactly one repository is configured with the old names, and it is
migrated by hand in the same move as this release. The fallback is
therefore a transition of days, not a feature anyone reading the release
notes or the configuration reference has to plan around.

Removed from `releases.html` and `docs/configuration.md`. The mechanism
itself is unchanged and stays described where it is worked on: in
`ConfigFiles`, in `StateDirMigration`, and in the migration plan.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/main/resources/templates/releases.html

@@ -18,23 +18,6 @@
                 configuration is <code>.werkator.yml</code>, the machine-specific one
                 <code>.git/werkator/.werkator.yml</code>, and all state — build results, artifacts,
                 worktrees, the control token — lives under <code>.git/werkator/</code>.</li>
-            <li>Every configuration is still found under its old name, spelled as it was:
-                <code>.gittally.yml</code> at the repository root, in a build worktree and as
-                committed on a branch, and <code>.git/gittally/.gittally.yml</code> for the machine
-                layer. The current name wins where both exist, and the old file is then ignored
-                rather than merged. The fallback is there because a configuration that is not found
-                is not an error — it leaves every setting at its default, so an installation that
-                updated without renaming would have come up looking healthy while having forgotten
-                its credentials and its builds. Rename at your convenience.</li>
-            <li>The state directory has no such fallback, so the first start after the update moves
-                it: <code>.git/gittally/</code> becomes <code>.git/werkator/</code>, with the build
-                history, the control token and the scheduled-build state in it. It moves only when
-                the old directory exists and the new one does not — where both exist nothing is
-                touched and a warning names the leftover. The build worktrees are dropped rather
-                than moved, since they point at their old path in both directions, and each is
-                recreated by its branch's next build. A generated systemd unit moves with the
-                directory and leaves its symlink dangling, which is warned about: re-run
-                <code>werkator init --systemd</code>.</li>
             <li>The default Gitea check context is <code>werkator</code>. Where the old name is
                 pinned in a branch protection rule, the rule has to be updated with it, or a pull
                 request waits forever for a check nobody posts any more. Statuses already written