docs: fix capitalization losses + one text corruption from the contractions pass

Review pass on top of the previous commit (85a94671) turned up three
real issues its own vale-only verification didn't catch:

- 'has not' -> 'hasn't' fired inside 'has nothing', corrupting
  docs/swarm/README.md into 'hasn'thing to say upward'. Restored
  'has nothing'.
- ~44 hits where the original text was genuinely sentence-initial
  ('It is', 'That is', 'They are', 'What is', 'Do not', ...) got
  contracted in lowercase, silently de-capitalizing the start of a
  sentence. Checked each one's real surrounding text and capitalized
  the ones that needed it.
- Confirmed (by reading the actual text, not just trusting vale) that
  the 3 remaining 'is not'/'has not'/'it is' hits after those fixes are
  vale's own false positives: it matches these as a bare substring with
  no trailing word boundary, so it also fires on 'is nothing', 'has
  nothing', and the already-correct 'it isn't'. Left those alone --
  there's no real issue in the text.

Re-verified with a fresh vale run: the remaining 17 hits are exactly
the union of the 14 legitimate ALL-CAPS/bold-emphasis skips from the
first commit and these 3 false positives. Full accounting in
/agents/iris/state/haiku-batches/contractions-report.md.

docs/swarm/secrets.md

@@ -19,7 +19,7 @@ so the store is a perfectly good place for it.
 
 **The generator and the reader are usually in different containers.** They share
 the host's network namespace, which makes them feel co-located, but their
-filesystem roots are separate. that's why delivery is a **host-side copy rather
+filesystem roots are separate. That's why delivery is a **host-side copy rather
 than a bind mount**: `nixos-container` refuses to start when a bind source is
 missing, and a secret minted on another container's first boot doesn't exist
 yet. Binding it would make one container wait on a file that waits on a
@@ -59,7 +59,7 @@ neither is a renaming of the other.
 | the secret store's unseal material                  | the HSM/TPM under `deploy.bao.seal = "pkcs11"`; openbao itself under `"shamir"`                      | in the token; or held by whoever ran `bao operator init`, which is what `"shamir"` means and why it's stated rather than inferred                                                                                                                                                                                                                                                  | n/a — only the host running the store seals anything                                                                                                                    |
 
 The three keys authelia mints for itself are generated in-container precisely
-because nothing outside that container ever reads them. **that's the test worth
+because nothing outside that container ever reads them. **That's the test worth
 applying to any secret added here** — and the client secret's plaintext half is
 the one row that fails it, which is the entire reason a delivery step exists.
 
@@ -80,7 +80,7 @@ secret isn't the container that reads it.
 The copy is only made when authelia is enabled **on this host** and something
 published is being scraped; otherwise no secret is needed and none is placed.
 
-⚠️ **don't read that delivery unit as the only way this collector is fed.**
+⚠️ **Don't read that delivery unit as the only way this collector is fed.**
 Whether it authenticates follows the _credential_, never another service's
 placement: a swarm collector may run on a host that holds neither store and no
 authelia, and then the secret is an ordinary operator-provided file named in
@@ -108,12 +108,12 @@ admit anyone to the queue, so it belongs wherever the responder runs and nowhere
 else.
 
 A hive that sets neither the public keys nor `autoGenerateCallout` fails at
-eval, naming the option it wants. that's deliberate: a queue that started
+eval, naming the option it wants. That's deliberate: a queue that started
 without them would accept `CONNECT {"user":"auth"}` from anyone sharing the
 host's network namespace, and nothing would look wrong until somebody connected.
 
 **All four or none** — the seed paths are required too, not just the public
-keys. they're two halves of the same pair: the server verifies with the public
+keys. They're two halves of the same pair: the server verifies with the public
 half, the responder signs with the private one. Supplying only the public keys
 used to pass eval and leave the queue with an auth-callout nobody answers, which
 refuses every client rather than degrading — and a refusal reaches the client as
@@ -163,7 +163,7 @@ internal CA deletes that file and names its own paths in
 `deploy.bao.serverCertFile` / `clientCaFile`; the store itself has no opinion.
 A hive that reads from a store on **another** machine names the reader's half —
 `clientCertFile`, `clientKeyFile`, `serverCaFile` — and places that leaf by hand.
-it's the one credential that can't come out of the store, being what opens it;
+It's the one credential that can't come out of the store, being what opens it;
 everything else a hive needs does.
 
 ## The constraint that decides where the root lives