A configured-but-unresolvable hash key silently downgrades the chain to unkeyed SHA-256

Problem/Motivation

resolveHashKey() returns an empty string when the configured Key entity is missing or resolves empty, and hashRow() then falls back to plain SHA-256. Nothing warns. A site that believes it has a signed, tamper-evident chain can have an unsigned one, and there is no way to tell from the data.

Steps to reproduce

Found on a real site while upgrading its consumer: hash_key was set to a Key entity that resolves correctly now, yet 1,997 of 2,002 rows verify under unkeyed SHA-256 and zero under HMAC. The key was almost certainly unresolvable in the environment where those rows were written, and every write quietly took the fallback.

Two consequences, the second worse than the first:

1. The chain is not actually signed, so anyone with database access can edit a row and recompute its hash. That is the entire property this module claims to provide.
2. Once the key does resolve, verify() recomputes every historical row with it and reports "BROKEN at row 1 — an entry has been inserted, deleted or edited". The diagnosis is wrong and alarming: nothing was tampered with, the rows were simply written unkeyed. Real tampering and a key that started resolving are indistinguishable.

Proposed resolution

Fail loud rather than silently downgrade. When hash_key is set but unresolvable: log an error naming the key on every write instead of falling through, and raise it on the status report via hook_requirements(). Whether to refuse the write outright needs discussion — dropping an audit entry is its own failure mode, so the safer shape is probably to write the row, mark it, and shout.

Record which key hashed each row. Without this, introducing or rotating a key makes all prior history unverifiable and indistinguishable from tampering. A key id or fingerprint column, consulted by verify(), would let a chain span a key change and still verify each segment under the key that produced it. This is the part that makes the guarantee survive normal operations.

Distinguish the failure in verify(). "Verifies under no key but not under the configured key" is a specific, recognisable state and should be reported as written unkeyed, not as tampering.

Remaining tasks

Worth noting that this exact class was already fixed once elsewhere: MCP Sentinel 1.13.0 made a declared-but-unresolvable webhook signing key refuse the delivery instead of silently sending unsigned. The same reasoning applies here, and arguably matters more — a webhook can be resent, a historical audit row cannot be rewritten.

The behaviour was inherited verbatim when the chain was extracted from MCP Sentinel 1.13, so any site upgrading to MCP Sentinel 2.0.0 with a keyed chain hits consequence 2 immediately.

Implementation notes: audit_chain issue 1.