pager4-1.4: a same-second stranger at a vacated path passes the tip proof (seed commits are byte-identical)

The one residual from #1853, split out so that issue can close on the landed fix
(#1878 / #1879 / #1881).

## What still fails

`pager4-1.4`: a **never-committed** database is renamed away while open, and a
*different* database is created at the vacated path **within the same second**. The
moved-file ownership check probes the file at the path for one of the handle's
branch tips; the stranger passes the probe and is adopted, so the write is not
refused:

```
expected: [1 {attempt to write a readonly database}]
got: [1 {no such table: t1}]
```

Any database with **one real `dolt_commit`** is protected — its tip is unique
content over its own data. The exposure is exactly: seed-only history, plus a
same-second stranger at the vacated path. No data is lost when it happens; the real
store is intact at its renamed path.

## Mechanism

Two databases created in the same second are **byte-identical**: the seed commit
hashes an empty parent, an empty catalog, the fixed message, NULL author/email, and
a second-resolution timestamp — same content, same hash (#1864, closed as correct
content addressing; Dolt is also second-resolution with no nonce). So the stranger
genuinely *contains* the handle's tip, and no content probe can separate them. This
is not a flaw in the tip probe; it is the limit of content addressing as an identity.

## Why this is parked

Every real fix changes something customers may now treat as stable, and there has
been no format change in over a month (decision deliberately deferred):

1. **Unique seed commit** — per-database entropy in the seed. The only
non-user-visible slot is a new commit format field (`DOLTLITE_COMMIT_V3`), the
#1547 area. Parking entropy in author/email/message is visible in `dolt_log`
forever and diverges from Dolt. Note this bends the commit format to serve a
pager-level question — the concern that closed #1872's first approach.
2. **Manifest store ID** — 16 random bytes minted at creation, carried forward by
GC's rewrite; 24 free bytes exist after `SELF_HASH` (offsets 144..167 of 168) and
`SELF_HASH` already covers new fields. Conceptually the right layer (file
identity answered by a store property, not VC content) and the probe collapses to
a header read, deleting the GC dependency entirely. Cost: every manifest writer
must preserve it, plus a legacy-zero-ID rule and a clone inherit-or-mint decision.
3. **Graph-lock sidecar record** — GC records the installed inode under the lock it
already holds. No database-format change, but the `.name-lock` file has been
zero-byte since it existed, so giving it a payload is an on-disk contract change
too, and it needs answers for a deleted sidecar (`tester.tcl` forcedeletes) and
torn writes.

If/when a format window opens, (2) is the recommendation on record: it fixes this
case *and* replaces the content probe wholesale rather than patching it.

## Guardrails already in place

- The gate carries the true reason:
`pager4-1.4 # two databases created in the same second are byte-identical, ...`
- `gc_tip_survival_test` pins the GC contract the current probe depends on, so this
issue is only about the same-second seed collision, not probe soundness.

Start with the pager4-1.4 failure and gc_tip_survival_test, then read the referenced #1547 commit-format area and manifest layout around offsets 144..167. Before implementation, resolve the deferred choice among a unique seed commit, manifest store ID, and graph-lock sidecar; done means the same-second stranger is rejected without weakening the existing GC tip-survival contract.

Written by the indexing model from the issue text.