op-supernode: Do not invalidate blocks on initiating-log storage errors

**Claude:** I found this during the interop implementation review.

Op-supernode converts initiating-log storage failures into protocol invalidity.

Event sequence:

1. `verifyExecutingMessage` calls `sourceDB.Contains` (`activity/interop/algo.go:213-215`).
2. `Contains` can return WAL read or block-record decode errors (`raftwallogdb/db.go:301-307`).
3. `verifyInteropMessages` treats every returned error as an invalid executing message (`algo.go:122-145`).
4. The round returns an invalid head and applies `DecisionInvalidate` (`interop.go:510-517,721-887`).
5. Op-supernode can therefore replace an otherwise valid block because its local log store failed.

This differs from executing-block reads. `OpenBlock` errors abort the verification round and retry later (`algo.go:100-103`).

Default backfill already covers the complete expiry window. This issue concerns storage errors, not custom backfill configuration.

Expected behavior: distinguish protocol-invalid lookups from local storage failures. Retry or halt on storage failures without invalidating the L2 block.