fix(policy): let the ref guard finish when history carries a policy it cannot read

[rmyndharis]

A .aimhooman.json this version cannot parse — a field a later version added,
say — made the final ref guard refuse every update that would introduce it.
git pull aborted. So did merge, reset --hard, and --no-verify, since
reference-transaction does not honour it.

Pulling the upstream fix did not help either. The revert's own scan resolves its
parent's policy, which is the unreadable commit, so that threw as well. Nothing
printed pointed at any way out.

The escape existed but was undocumented and unhinted:
git -c core.hooksPath=/dev/null pull fast-forwards in one command, and
git checkout <sha> works through the detached-HEAD carve-out. Uninstalling was
never the only option, but nothing said so.

What changed

History is not the receiving developer's to fix, so the change belongs in policy
resolution rather than in the guard's catch.

resolvePolicy takes a tolerant flag for commit targets. With it, an
unparseable policy returns a result carrying profile: null and the parse
message instead of throwing. scanCommit asks for tolerance only when its
caller does, falls back to the profile local config can reach, and pushes a
warning naming the commit it could not read.

The strict floor stays conservative: a parent whose policy is unreadable counts
toward it. An unparseable file must not be a way to switch strict enforcement
off, which is what ignoring it would mean.

headPolicy takes the same flag, since HEAD is itself a commit and reading it
for the migration-ack baseline threw for the same reason.

The fallback is sourced from local config rather than the staged policy. During
a fast-forward the index holds the same unreadable blob, so the staged route
would fail the same way.

What did not change

The worktree and the index keep the hard error. So does anything the developer
asked about directly: check --commit and audit should say plainly that the
file is unreadable, because there the loud answer is the right one. Only the
guard that runs over incoming history is tolerant, and it reports every fallback
it made.

Tests

Two added. Tolerant commit resolution returns the parse error instead of
throwing, while the direct call still throws. A commit scan with tolerance
finishes under a reachable profile and names the commit in its diagnostics,
while the same scan without tolerance still refuses.

Full suite green, npm run check green.