chore(repo): name the vault repo after what it holds, not the engine

[wshallwshall]

What changed

wshallwshall/MessageFoundry is now wshallwshall/MessageFoundry-vault, and its
GitHub description now names what it holds instead of describing the engine.

It shared a name AND a description with the public engine repo
MEFORORG/MessageFoundry, so two rows in gh repo list read as one project.

	before	after
name	wshallwshall/MessageFoundry	wshallwshall/MessageFoundry-vault
description	"Lightweight code-first HL7 v2 integration engine (Python)"	"Private records vault for MessageFoundry. Holds the ASVS scorecard, role playbooks, and session handoffs. The engine itself is MEFORORG/MessageFoundry."

Three commits, one layer each: the engine-side sweep of the 13 old-slug
references across 8 files, a guard so the tree stays swept, and BACKLOG #1463 for
a gap the work uncovered.

Why the rename disabled nothing

Checked BEFORE renaming. The 9 hardcoded old slugs in the vault sit in cla.yml
and release.yml, both disabled_manually. Every ACTIVE vault workflow either
checks out MEFORORG/MessageFoundry explicitly or reads the github.repository
context, which follows a rename. PyPI Trusted Publishing is bound to
MEFORORG/MessageFoundry, not to the renamed repo.

Two sites are not a plain substitution

• scripts/hooks/durability_push.sh documents git remote -v output, so its
  remote table had to match the URL the remote now carries. Both local remotes
  were repointed and verified with git ls-remote against the new URL.
• docs/LEDGER-GATE.md quotes the URL a REFLOG literally recorded. That string
  stays as recorded, with the current name named beside it. Rewriting it would
  make the doc disagree with the artifact the section is reading.

The guard, and why a rename needs one

GitHub keeps a permanent redirect from the old path, and their documentation
names exactly one way to drop it: create a new repository claiming the old name.
That would put the engine's name back in the account listing, so the redirect
stays. The cost is that a stale reference does not fail. It quietly answers,
correctly, about the vault, under a name that is gone.

scripts/quality/stale_repo_slug_check.py greps the tracked tree and fails on the
pre-rename slug, wired as a pre-commit hook with always_run and
pass_filenames: false.

Two design points worth a reviewer's attention:

• It never writes the old slug as a literal. The needle is assembled from
  parts. Written whole, the guard and its test would each violate the rule they
  enforce, and exempting the guard from itself would make it the one place a real
  stale reference can hide. The accepted cost: grepping the tree for the old slug
  will not find the guard.
• The one exemption is pinned to a count, not a path. docs/LEDGER-GATE.md
  may hold exactly 1. A path-level exemption would blind the guard to every
  future stale reference in that same file, so drift in either direction fails.

A clean-tree arm proves nothing on its own, so the 12 tests plant violations and
require the guard to see them: a bare slug, a bare slug hiding on a line that also
carries the current one, the pin drifting up, the pin drifting down, an untracked
file staying out of scope, and two git-failure arms, because "no matches" and "the
search never ran" are the same empty output. The missing-root arm found a real
gap and the guard was fixed rather than the test -- an OSError was reaching the
caller as a traceback instead of exit 2.

End-to-end control run by hand: a planted probe made the WIRED hook exit 1 naming
the site, and removing the probe returned Passed.

The guard then refused this PR's own backlog filing, which quoted the drift
diff verbatim. That is the design working: it cannot tell quoted evidence from a
live reference. docs/BACKLOG.md was deliberately NOT given a count exemption --
23,000 lines growing daily would make the pin a reflex rather than a decision --
so the item describes the diff instead and records why.

BACKLOG #1463, filed here

install-git-hooks.ps1:436 lays scripts/hooks/durability_push.sh down as
.git/hooks/post-commit verbatim, and every instrument that could report it
drifting tests a MARKER rather than content:

• install-git-hooks.ps1:162 sets $durInstalled by matching a marker the
  installer itself writes in, so it answers "is this ours" and never "is this
  current". :164 prints the presence string off it, with no hash.
• The parity test tests/test_installed_coord_hooks.py:353 is parametrized at
  :352 over PAYLOADS, parsed at :231 from the installer's own
  $payloads = @("claim_check.py", "push_guard.py"). The test's scope IS the
  installer's scope by construction, and it inherits the gap.
• tests/test_durability_hook_provenance.py does drive a post-commit hook. Its
  docstring at :32 says the fixtures never touch the real one -- correct for a
  provenance test, and it means the file whose name most suggests coverage here
  provides none.

commit-msg and pre-push are thin shims that locate a hashed .py payload, so
a marker is enough for them. post-commit has no payload: the body IS the
implementation, and nothing hashes it.

This was found the hard way -- a direct diff was the only thing that reported it,
while -Status printed IN SYNC hash pairs for both payloads and, for the
drifted file, the word INSTALLED.

Checks run

check	result
ruff check + ruff format --check	clean
mypy strict on messagefoundry	268 files, no issues
mypy --strict on both new files	no issues
bandit	passed, after the repo's usual nosec for a fixed-argv read-only git call
scripts/docs/backlog_status_check.py	671 items, each declaring exactly one status
parse_items on the new item	#1463 parses as open
pytest guard suite	12 passed
pytest test_tooling_partition (pins the new manifest entry)	passed
pytest test_required_workflow_state, test_durability_hook_provenance, test_coord_alloc_strand_sweep	40 passed
all pre-commit hooks, all three commits	passed

Full pytest was not run. Hosted-runner legs (for example
windows-service-smoke) must be read from CI after this process exits.

Two things this PR does not do

The installed hook still needs a manual reinstall. .git/hooks/post-commit
carries the pre-rename remote table. Fixing it means writing into the shared
.git of the primary checkout, which 38 worktrees share, so it is the owner's
hand:

pwsh -NoProfile -File scripts/coord/install-git-hooks.ps1

Both payloads already report IN SYNC and this branch is 0 commits behind
origin/main, so the reinstall cannot downgrade anything -- the only content
change is the two comment lines.

A stale measurement was left as recorded. docs/adr/0160-*.md line 455 says
the vault reports "every workflow except ASVS scorecard" as
disabled_manually. Measured today: 6 are active (ASVS scorecard, ASVS verifier
drift, Branch leak scan, SDS citations, SDS standard freshness, threat-model
drift) plus Dependabot Updates and Dependency Graph. It is a dated 2026-08-06
measurement inside a "measurements that produced that decision" block, so
correcting it is its own change, not a side effect of this one.

Five live peer sessions were mailed before the shared private remote URL
changed under them.

🤖 Generated with Claude Code

[wshallwshall]

Lander note: the ledger conflict is resolved, but this PR has a real red of its own.

I merged main and resolved the docs/BACKLOG.md conflict; this PR is now MERGEABLE. Five checks still fail, and only one of them is the repo-wide gitleaks outage that is currently reding every open PR. The rest are this branch's.

tests/test_gate_ci_mirror_parity.py::test_this_file_and_its_sibling_together_cover_every_hook

AssertionError: hook(s) ['stale-repo-slug'] are declared in .pre-commit-config.yaml
and covered neither here nor by tests/test_lint_scope_parity.py.
Add the CI mirror and list it in _MIRRORS, or record deliberately why it has none.

Measured, with the instrument's own output checked first because a colon-path git show on this box silently mangles the argument and returns a plausible zero:

	stale-repo-slug occurrences
.pre-commit-config.yaml on origin/main	0
.pre-commit-config.yaml on this branch	1
tests/test_gate_ci_mirror_parity.py on this branch	0

So this branch adds the hook and never mirrors it. That is not fallout from my merge, which touched docs/BACKLOG.md only. The failing test names the remedy in its own words, and either half of it is fine: add the CI mirror and list it in _MIRRORS, or record deliberately why this hook has none.

Nothing here can merge until gitleaks is fixed on main regardless, so there is no rush on the fix, but it will not land without it.