Improve two-safe governance state visibility

[rvagg]

Pulling this out of #12 as a separate item for us to loop back on later when we have a larger picture.

Governance state should be inspectable without decoding raw storage or reconstructing the entire contract history. We should define a canonical read and event pattern needed for Safe operators, objection-window watchers, dapps and incident diagnosis.

One hypothetical scenario I imagine is having two operators claiming they submitted the same action and it wasn't executed. Perhaps their arguments differed, but how would we diagnose that was the cause and who has the ability/expertise to do that?

Some possible items to consider:

• Define task states: collecting approvals, holding, executable, executed and vetoed.
• Expose current owners with stable bit/address correspondence.
• Expose a task by ID, including approvals, owner-set version, approval epoch and ready epoch.
• Emit the proposed operation or perhaps just sufficient canonical data to decode it.
• Emit unanimity/ready, veto and execution lifecycle events and document the clear pattern.
• Define event-indexed discovery of pending tasks versus on-chain enumeration.

[wjmelements]

I think all of the items here are already handled by events. If we don't think events are sufficient we can add additional state such as a current owners roster.

#12 (comment)

One hypothetical scenario I imagine is having two operators claiming they submitted the same action and it wasn't executed. Perhaps their arguments differed, but how would we diagnose that was the cause and who has the ability/expertise to do that?

Emit the proposed operation

SafeL2, such as the v1.4.1 that owns FWSS, emit transaction data (which becomes msg.data). It can be decoded using the ABI json.