fix(llm): explain intended actions behind Safe approvals

[spalen0]

Queued approveHash(bytes32) alerts currently leave the referenced transaction's impact unknown and can give the receiving Safe the calling Safe's label. Look up the referenced transaction and explain its intended action, while keeping caller and target identities explicit.

For the CAP alert at outer nonce 256, the referenced transaction adds an owner and sets the receiving Safe's threshold to three. Current state shows that separate execution would change its configuration from 1-of-5 to 3-of-6. The approval itself executes no transaction and moves no funds.

The shared adapter covers CAP, Yearn, and other configured Safe networks. Each uncached approval makes one Safe transaction service request; found action fields are cached across monitoring runs. Raw calldata is decoded locally for Safe administration or through the existing decoder for other calls. Optional owner/threshold/nonce reads apply only to Safe administration self-calls. Consumed nonces suppress prospective changes, and invalid thresholds are identified as reverting against current state. An unavailable state read still preserves the decoded intended action.

Prompt and report context contain the referenced action, its service provenance, and any relevant configuration change. The report contains facts with linked addresses. Missing or malformed service records retain an explicit unresolved reason. Mutable Safe configuration and missing records are never cached.

Validation: 1,729 tests passed, 4 skipped, 53 subtests passed. Repository-wide Ruff lint/format, ty, and prek run --all-files passed. A read-only check of the actual CAP transaction reproduced the intended owner addition and 1-of-5 to 3-of-6 change. Regression tests cover both reported nonce/threshold issues, persistent payload caching with fresh configuration reads, and API/RPC failures.

References: original CAP report, referenced Safe transaction.