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>

docs/configuration.md

@@ -12,11 +12,6 @@ Werkator is configured via YAML files. Settings are merged from several sources
 
 The repo install config (`.git/werkator/.werkator.yml`) wins on any key present in both files. Typically used to set `git.token` and `git.account` without committing them.
 
-Each of the three is also looked up under the name it had before the rename to Werkator, spelled exactly as it was: `.gittally.yml` at the repository root and in a build worktree, `.git/gittally/.gittally.yml` for the machine layer.
-The current name always wins; where both exist the old file is ignored, never merged.
-The fallback exists because a missing configuration is not an error — it leaves every setting at its default, so an installation that updated without moving its files would come up looking healthy while having forgotten its credentials and its builds.
-Rename the files at your convenience; the fallback goes away with a future release.
-
 ### Which Werkator a file is written for
 
 Every configuration file may declare the Werkator it was written for. Without it, a

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