Fixed two spots that failed toward the permissive answer

[kridaydave]

PR made by step-5-preview from opencode on behalf of Kriday.

Two Low-severity drift entries from the repo's own drift table, both the same shape: code that spotted something wrong and produced a value that looked fine anyway.

hex_to_bytes mapped an unparseable hex pair to 0 and carried on, so a corrupt digest still rendered as a well-formed SRI string. The only place such a digest ever surfaced was the mismatch message naming the expected value, which meant an operator got a confident looking digest with bytes silently zeroed. It is fallible now, and to_sri returns a Result for the same reason.

Three permission hardening steps in store.rs were written as let _ =, so their failures were invisible. The pre-create at 0o600 was the load-bearing one. Connection::open creates the database file at whatever the umask allows, so when the pre-create failed the database still came up, just at a default mode. The step whose whole job was narrowing it had failed without saying so. All three propagate now.

Summary:

• hex_to_bytes refuses a digest that is not clean hex instead of mapping a bad pair to byte 0
• Checksum::to_sri returns Result, so the decode failure has somewhere to go
• The three let _ = permission steps in store.rs now propagate: the 0o700 directory chmod, the 0o600 pre-create, and the 0o600 database chmod
• Both fixes pinned by tests that were reverted and re-run to confirm they fail without the fix

No behaviour change on the success path. The modes were already being set and the honest digests already round-tripped. Only the failure handling was missing, and enforces_unix_file_and_directory_permissions still pins the resulting modes.

Mutation testing over both changed files found three survivors, all in code this change does not touch: audit_entries, default_db_path, and the sha512 length guard in parse_token. All three are pre-existing and untested. Recorded in the drift notes rather than folded in here.

Toolchain caveat: there is no rustup on this machine, so rust-toolchain.toml is inert and the local gate ran on system rustc 1.98.1 rather than the pinned 1.97.1. A green local run here is necessary, not sufficient.