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/0001-2026-06-09.test-framework.md

@@ -10,7 +10,7 @@
 
 ## Context and Problem Statement
 
-werkator is a greenfield Kotlin/Spring Boot project.
+Werkator is a greenfield Kotlin/Spring Boot project.
 A test framework must be chosen before writing any tests.
 
 The framework shapes how tests are structured, how readable they are, and how well they integrate with the Spring Boot test slice infrastructure.

docs/adrs/0002-2026-06-09.gradle-version.md

@@ -10,7 +10,7 @@
 
 ## Context and Problem Statement
 
-werkator is a greenfield Kotlin/Spring Boot project.
+Werkator is a greenfield Kotlin/Spring Boot project.
 A Gradle version must be chosen for the initial setup.
 
 [Gradle 9](https://docs.gradle.org/9.3.0/release-notes.html) (currently 9.5.1) is now stable and available.

docs/adrs/0003-2026-06-09.spring-boot-version.md

@@ -10,7 +10,7 @@
 
 ## Context and Problem Statement
 
-werkator is a greenfield Kotlin/Spring Boot project.
+Werkator is a greenfield Kotlin/Spring Boot project.
 A Spring Boot version must be chosen for the initial setup.
 
 The choice is constrained by the support lifecycle: as of June 2026,

docs/adrs/0004-2026-07-07.rewrite-architecture.md

@@ -64,7 +64,7 @@ nginx/Let's Encrypt container management was not ported; `init --systemd` genera
 
 #### Disadvantages
 
-- HTTPS setup is a manual, host-specific step outside werkator's control.
+- HTTPS setup is a manual, host-specific step outside Werkator's control.
 
 ## Decision Outcome
 

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
 

docs/adrs/0006-2026-08-10.runtime-bundle-distribution.md

@@ -6,20 +6,20 @@
 - rejected: -
 - superseded: -
 
-**Decision [accepted]:** werkator is distributed for hosts without a Java runtime as a self-contained runtime bundle — a jlink-trimmed JRE plus `werkator.jar` plus a launcher script in one tarball, built by `./gradlew runtimeBundle`.
-The JAR stays the primary artifact; a GraalVM native image and a containerized werkator runtime were rejected.
+**Decision [accepted]:** Werkator is distributed for hosts without a Java runtime as a self-contained runtime bundle — a jlink-trimmed JRE plus `werkator.jar` plus a launcher script in one tarball, built by `./gradlew runtimeBundle`.
+The JAR stays the primary artifact; a GraalVM native image and a containerized Werkator runtime were rejected.
 
 ## Context and Problem Statement
 
-werkator must run on Hostsharing container servers (the primary target, see ADR 0005).
+Werkator must run on Hostsharing container servers (the primary target, see ADR 0005).
 These hosts provide git, Docker, make, and systemd user sessions, but no Java runtime, and nothing may be installed system-wide.
-`docs/bootstrapping.md` sketched a containerized werkator runtime as the future answer; that sketch was never validated against the operational details.
+`docs/bootstrapping.md` sketched a containerized Werkator runtime as the future answer; that sketch was never validated against the operational details.
 
 ## Considered Options
 
 * jlink runtime bundle (trimmed JRE + jar + launcher, one tarball)
 * GraalVM native image (single executable)
-* Containerized werkator runtime (the original `docs/bootstrapping.md` sketch)
+* Containerized Werkator runtime (the original `docs/bootstrapping.md` sketch)
 
 ### jlink Runtime Bundle
 
@@ -44,12 +44,12 @@ Bad:
 
 ### GraalVM Native Image
 
-Rejected because Spring AOT evaluates bean conditions at build time, and werkator's dual-mode wiring cannot be represented in a single AOT arrangement:
+Rejected because Spring AOT evaluates bean conditions at build time, and Werkator's dual-mode wiring cannot be represented in a single AOT arrangement:
 the CLI context runs without web and with `@Profile("!server")` `CliRunner`, while the `server` subcommand starts a second `SpringApplication` with `WebApplicationType.SERVLET` and the `server` profile gating the watcher/metrics/nginx lifecycles.
 Whichever profile and web type the AOT processing fixes, the other mode's beans are missing from the binary.
 Supporting both would require replacing the profile wiring with runtime guards and collapsing the two context shapes — an invasive rewrite with regression risk for the JVM path, on top of the usual native-image reflection work (Jackson-bound config and persistence classes, picocli).
 
-### Containerized werkator Runtime
+### Containerized Werkator Runtime
 
 Rejected for operational complexity: the image must bundle git and docker CLIs; the container needs a same-path `$HOME` mount plus a docker-socket mount and uid/gid mapping so that `DockerBuildRunner`'s `--volume $workspace:$workspace` sibling mounts keep working; and the systemd unit must be hand-edited to a `docker run` invocation.
 This remains the documented fallback if the runtime bundle ever becomes unworkable.

docs/adrs/0007-2026-08-28.build-definitions.md

@@ -11,7 +11,7 @@
 
 ## Context and Problem Statement
 
-werkator's configuration is branch-centric: `branches.<name>` holds the build settings, and the nightly schedule (`autoBuild`) hangs off the branch.
+Werkator's configuration is branch-centric: `branches.<name>` holds the build settings, and the nightly schedule (`autoBuild`) hangs off the branch.
 v0.9.13 added a per-slot `buildCommand` and `name` to `autoBuild.times[]`, so a nightly slot could run a fuller check recorded in its own result pool.
 That worked, but it is a job concept hidden inside a schedule entry: the slot carries a command, an identity, and (implicitly) a branch — everything a job has, in the wrong place.