docs: correct admiralty ancestry status

docs/admiralty-fleet-repo.md

@@ -33,8 +33,8 @@ vessel: updated e52cc76..492361e
 FF_STATUS=updated
 ```
 
-This fork's `main` has since advanced past `e52cc76`, so its tip is no longer an ancestor of `492361e`; it stood at `ce43899` when this document was written.
-A vessel sitting at the fork's current `main` and pointed at `admiralty`'s `main` would therefore hit exactly the refused advance described above, and how that is repaired before cutover is still open; see "What is not built yet".
+This fork's `main` has since advanced past `e52cc76`, so its tip stopped being an ancestor of the original `admiralty` tip.
+Measured again on 2026-08-05 UTC, `admiralty` has absorbed history through the newer pin `b5c0bf6`, but this fork's `origin/main` had already advanced 36 commits past that pin again; see "What is not built yet" for why each later pin bump needs the same ancestry repair.
 
 ## The shape of the repository
 
@@ -154,9 +154,13 @@ None of that means the canonical upstream template absorbed those patches: the v
   Ancestry is a property of the commit graph and not of tree content, so a pin bump alone does not restore it: a bump commit on `admiralty` copies the fork's newer tree, but it does not add the fork's newer commits to `admiralty`'s ancestor set.
   Absorbing that history so an already-updated vessel stays fast-forwardable needs a true merge of the fork's `main` into `admiralty`'s `main`, which is consistent with the standing rule that upstream-sync pull requests land as true merge commits rather than squashes.
   How such a merge interacts with the drift gate is no longer the open part: `admiralty`'s own `fleet/doctrine/pin-and-bump.md` owns the merge-bump procedure, including regenerating the manifest in that same commit and the verification to put in the pull request.
-  What remains open is that the procedure has not been applied.
-  The 2026-08-01 pin bump to `de0b95b` landed as an ordinary single-parent commit rather than a merge, so it copied the tree without absorbing the history, and even a vessel sitting exactly at the current pin cannot fast-forward onto `admiralty`.
-  Measured on 2026-08-01 UTC in a throwaway clone of `Freudator86/admiralty` whose `main` was `285289c24be625f5b27d5ae846dd09024114534c`, with this fork fetched into it so both sides are present: `git merge-base --is-ancestor de0b95b7a13e72256089707aeab6aac83d00e90d 285289c24be625f5b27d5ae846dd09024114534c` exits 1, and the newest fork commit that is still an ancestor of that `admiralty` `main` is `bbf0023` of 2026-07-30.
-  Name the `admiralty` commit rather than a bare `origin/main`, because in this repository `origin/main` is the fork itself, where `de0b95b` is an ancestor and the same command exits 0.
-  That merge bump cannot be raised through no-mistakes, because its rebase would flatten the ancestry the merge exists to create, so it is authorized on the captain's word instead.
+  **The procedure has since been applied.**
+  `admiralty`'s `chore(pin): bump vendored firstmate to b5c0bf6` (commit `4bf4acfd3f9eb5ad6edc99e84c2221843f0b500b`, 2026-08-04) lands as a true merge: its second parent is this fork's `b5c0bf65d43ca274e8f8ae3b700426d614e7585c`, so `admiralty`'s ancestor set now includes the fork's history up to that commit, not just its tree.
+  A vessel sitting exactly at that pin can now fast-forward onto `admiralty`.
+  Measured on 2026-08-05 UTC in a throwaway clone of `Freudator86/admiralty` whose `main` was `d16bf0cd19c316376f77615f46fd0e8e85fde45a`, with this fork fetched into it so both sides are present: `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c d16bf0cd19c316376f77615f46fd0e8e85fde45a` exits 0.
+  Name the `admiralty` commit rather than a bare `origin/main`, because inside that clone `origin` is `admiralty`, while in this repository `origin` is the fork; the same command against the wrong side answers a different question.
+  The newest fork commit that is an ancestor of that `admiralty` `main` is the pin itself, `b5c0bf6`, dated 2026-08-04: the merge absorbed the fork's history exactly up to the commit it pinned, no further.
+  This fork's `main` has since advanced past the pin again: in this same review pass, `git merge-base --is-ancestor b5c0bf65d43ca274e8f8ae3b700426d614e7585c origin/main` exits 0 and `git rev-list --count b5c0bf65d43ca274e8f8ae3b700426d614e7585c..origin/main` reports 36 commits.
+  The same open question - restoring ancestry as the fork keeps moving - recurs at every pin bump, and each one needs its own merge, not just the first.
+  That merge bump cannot be raised through no-mistakes, because its rebase would flatten the ancestry the merge exists to create, so each one is authorized on the captain's word instead.
 - The Bridge extraction, the fork-maintenance tooling retirement, and the Bucket-A upstreaming are unstarted; the fork-first ratchet prices each as its own reviewed pin bump.