Name the two kinds of pinned key: host-pinned and master-pinned

Pinning is one rule — strip the key from the branch layer — but the keys
fall into two groups by where they are meant to live: what only the
machine can know, and what belongs in the repository yet must not be
decided per branch. docker.enabled/network moves from the first group to
the second once the committed config carries it.

The KDoc says explicitly that the distinction is documentary, so nobody
looks for two mechanisms in stripPinned.

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

src/main/kotlin/de/hoennig/gittally/config/ConfigLoader.kt

@@ -125,6 +125,15 @@ class ConfigLoader(
      * sections, the trust gate, and the docker sandbox policy — the latter two wherever
      * they may appear, in a `builds` definition as well as in a legacy `branches` entry.
      * See [loadWithBranchLayer].
+     *
+     * There is one rule here, not two: a pinned key is dropped from the branch layer and
+     * then resolves from whichever remaining layer sets it. The documentation still names
+     * two groups — *host-pinned* for what only the machine can know (`git`, `server`) and
+     * *master-pinned* for what belongs in the repository but must not be decided per
+     * branch (`gitea`, `executor`, `watcher`, `requirePullRequest`, `statusContext`).
+     * That distinction says where a key is meant to live, not how it is stripped, and it
+     * is not visible here: `docker.enabled`/`network` moves from the first group to the
+     * second as soon as the committed configuration carries them.
      */
     @Suppress("UNCHECKED_CAST")
     private fun stripPinned(branchLayer: Map<String, Any?>): Map<String, Any?> {