Rename GitTally to Werkator

`gitTally` is the name of another product in the git space, so the
rename is a precaution; nothing about what the build system does changes.

The name follows one rule: `Werkator` where it is prose, capitalized
where it is a Kotlin type and its file, lowercase everywhere a machine
reads it — the command, packages, paths, configuration keys and values,
the Gitea check context. Environment variables keep their convention and
are uppercase throughout.

Every configuration file is still found under its pre-rename name
(`ConfigFiles`): `.gittally.yml` at the repository root, in a build
worktree and as committed on a branch, `.git/gittally/.gittally.yml` for
the machine layer. The current name wins where both exist, and the old
file is then ignored rather than merged — two files side by side are a
half-done rename, not a layering. Without the fallback an installation
that updated without renaming would not fail: a configuration that is
not found leaves every setting at its default, so it would come up
looking healthy while having forgotten its credentials and its builds.

`docs/werkator-migrationsplan.md` lists what the fallback does not
cover and has to be moved by hand — above all the state directory
`.git/werkator/`, which holds the build history, the control token and
the worktrees, and has no fallback of its own.

`docs/migration-from-legacy.md` is deleted with this: it mapped the
legacy script's environment variables, and every host it addressed has
long since moved to the YAML configuration.

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

docs/adrs/0005-2026-07-07.managed-nginx-tls.md

@@ -6,7 +6,7 @@
 - rejected: -
 - superseded: -
 
-**Decision [accepted]:** werkator optionally manages an nginx+certbot Docker container for hosts without a usable reverse proxy — revises the "no managed nginx" part of ADR 0004; deployment behind an existing reverse proxy stays the default.
+**Decision [accepted]:** Werkator optionally manages an nginx+certbot Docker container for hosts without a usable reverse proxy — revises the "no managed nginx" part of ADR 0004; deployment behind an existing reverse proxy stays the default.
 
 ## Context and Problem Statement
 
@@ -15,16 +15,16 @@ That decision was carried over from the rewrite plan without validating it again
 
 ### Technical Background
 
-werkator must run on Hostsharing managed container environments.
-These hosts provide Docker but no root access and no host web server that werkator could sit behind.
-Without the managed nginx container, werkator cannot be served over HTTPS there at all.
+Werkator must run on Hostsharing managed container environments.
+These hosts provide Docker but no root access and no host web server that Werkator could sit behind.
+Without the managed nginx container, Werkator cannot be served over HTTPS there at all.
 The legacy script already solved this: it wrote an nginx config, ran an nginx Docker container, and obtained/renewed Let's Encrypt certificates via a certbot container in webroot mode.
 
 ## Considered Options
 
 * Keep ADR 0004 as is (host reverse proxy only)
 * Re-add the legacy managed nginx+certbot container as an opt-in feature
-* External tooling (user-maintained compose stack next to werkator)
+* External tooling (user-maintained compose stack next to Werkator)
 
 ### Host reverse proxy only
 
@@ -38,7 +38,7 @@ The legacy script already solved this: it wrote an nginx config, ran an nginx Do
 
 ### Opt-in managed nginx+certbot container
 
-werkator starts and supervises a labelled nginx container and handles certificate issuance/renewal via certbot, only when explicitly enabled in the config.
+Werkator starts and supervises a labelled nginx container and handles certificate issuance/renewal via certbot, only when explicitly enabled in the config.
 
 #### Advantages
 
@@ -54,7 +54,7 @@ werkator starts and supervises a labelled nginx container and handles certificat
 
 #### Advantages
 
-- Keeps werkator itself simple.
+- Keeps Werkator itself simple.
 
 #### Disadvantages