Bind a directive to an authorised signer, not to a signature

[MongLong0214]

Summary

Closes #597.

A signature proves that a key the verifier trusts signed the commit. It does not prove that the
signer has authority over this repository. Signature mode treated the two as the same thing: a
valid signature plus an author header matching a configured string was enough to emit directive.

Repository policy now names the signer fingerprints it authorises, and Git's own reported signer is
compared against that list.

What changed

• a repository-local allowlist of approved signer fingerprints
• the grade is decided from the fingerprint Git reports (%GF), not from the author header
• absent, empty, and unreadable policy all authorise nobody — a missing list is not permission
• the default author-string mode is unchanged and still documented as non-authenticated

Test plan

Real signatures throughout. The fixture generates throwaway GPG keys and signs commits with them;
nothing here asserts against a mocked verification result.

• a valid signature by an unapproved key grades claim
• a forged author header on a commit signed by an unapproved key grades claim
• an approved signer grades directive on both the commit and the notes route
• the approved commit returns the same grade on every core record route
• 5 cases in signer-authority, 380 across grade, trusted-authors, query and guard
• npx tsc --noEmit
• canonical build and npm run artifact:verify

Negative controls. Removing the authorisation check makes both refusal cases grade directive
where they must grade claim; restoring it returns them to claim. Both pairs pasted below in the
commit record.

What this does not claim

No PKI, no hosted identity service, no automatic key enrolment — those are ruled out by the issue's
own non-goals.

Signatures are not required by default. Making them mandatory would demote every existing
repository's records on upgrade, which an existing decision record on this repository rules out.

An approved signature still establishes only that an authorised key signed this commit. It does not
establish that the record's content is true, and the product does not say otherwise.

[github-actions]

CommitLore — record lint

Trailers: clean — 3 commits in origin/main..bc81ced3d668b7537fe1c98d8dea6e910aa8c24d
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 64 paths; query one path at a time to follow its rename chain (64 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}