Close the approval-forgery hole: check every write, not just additions

Close the approval-forgery hole: check every write, not just additions

The check that an approval is written by the principal it names used
`--diff-filter=A`, so it only looked at newly added files. An approval that already
existed could simply be edited: approve commit A, then rewrite approvals/<me>.json
to name commit B and land B with the approver's name on it. A test now demonstrates
that exact forgery before the fix and refuses it after.

The check is now driven by the change status of every path: any non-deletion on
`approvals/<name>.json` requires the actor to be `<name>`, and the first push (no
old commit to diff, so every approval in the tree is new) is checked the same way.
Deletion is limited to the owner, because removing someone else's approval forges
nothing but erases their statement; an admin may still do it, and that is written to
the audit log rather than happening silently.

Renames land in the same net: without rename detection a move appears as an add,
which the check sees, and the destination path is what the check reads.

Also worth recording what the enforcement actually rests on, since the file name is
the only name that carries authority: the SSH handshake resolves the presented key
to a user through data/trusted_keys/<user>.keys, that mapping is one-to-one (a key
already owned by another user is refused at add time and fatal at load), and the
resolved name reaches the hook as VOLE_ACTOR, which the client cannot set because
the exec surface is a two-entry whitelist. `author` fields in meta.json remain
display-only and decide nothing.

The remaining limitation is honest: this is enforcement at push time, not proof at
read time. A clone shows that an approval file exists, not that the server saw its
owner write it. Signed attestations in Phase 7 are what would make it verifiable
offline.