Late-write recheck: follow-ups from the #1669 review #1670

Follow-ups from the round 1 review of #1669 (late-write recheck). None of these hands a refuted write back as verified, but each leaves a person or an agent with less to go on.

1. Owed rechecks are lost on a restart, with no trace. openadapt verify serve holds provisional results in memory (VerifyBridge._rechecks). After a restart, openadapt verify ledger list shows nothing pending, and the attempt's ledger state is a plain CONFIRMED. The values were pruned from attempt.json, so a person needs the agent's original values to run the Python recheck from recheck.json. Record "recheck owed until T" in the ledger, or in a file under the state directory that ledger list reads.
2. The same error for a spent recheck and a lost one. verify_recheck says "no provisional result for that write_id" both when the recheck already ran and when the server restarted. Tell them apart.
3. A stale provisional on earlier_result. AlreadyWritten.result, and the MCP earlier_result, keep provisional: true and a past recheck_due_at for good, also after a confirming recheck. A retrier gets no next and no way to recheck.
4. The reason text when the recheck call itself is wrong. A recheck called with the wrong params or actor (a caller bug) gives UNCERTAIN and re-resolves a correct write for review. That is fail-closed, but the reason should say that the recheck call was wrong, not the write.
5. UNCERTAIN wording in VERIFY_WRITES.md. Its recheck table says UNCERTAIN means "couldn't be read again, or was still changing". It is also given for a state not issued here, mismatched params or actor, and a change that a later refuted write may own.