[Task]: Add typed side effects for governance data flows

[rian-be]

Summary

Evolve side effects beyond loosely typed payloads so they work better with persistence, querying, and integrations.

Goal

Introduce typed or contract-based side effect payloads that can survive governance persistence and downstream integration scenarios.

Problem

As long as side effects are only runtime output, loose payload typing is tolerable. Once governance data is persisted, queried, or integrated with external systems, side effect contracts need to become more explicit.

Scope

• Add SideEffect<TData> or equivalent typed side effect contract
• Define serialization / registration contracts for side effect payloads when needed
• Ensure typed side effects integrate with governance persistence and query flows
• Update runtime and examples to demonstrate typed side effect usage

Design Expectations

• Typed side effects should preserve the lightweight core experience where possible.
• Persistence and query flows should not have to guess payload shape.
• Side effect typing should remain compatible with governance audit/history use cases.
• The model should make it obvious which side effects are stable integration contracts vs incidental payloads.

Acceptance Criteria

• Side effect payloads have an explicit contract beyond object?
• Persistence and query flows can work with side effect payloads predictably
• Examples or docs show the intended usage pattern
• Governance data flows do not lose side effect meaning during serialization

Non-Goals

• This issue does not require a full event-sourcing model
• This issue does not add external delivery infrastructure by itself
• This issue does not redesign all existing side effect APIs in one step unless needed

Notes

This becomes more important once governance data is persisted and queried rather than only emitted at runtime.