Evaluate reducer composition ergonomics before adding optics

## Summary

Evaluate reducer-composition ergonomics after the runnable composition example has exercised the current API.

RFC 0014 deliberately uses shared/mutable function-item accessor pairs at each composition boundary. That shape supports both `reduce(&mut State, ...)` and `subscriptions(&State)` without introducing a lens trait. We should not add optics, macros, or another public abstraction based on aesthetics alone.

## Investigation

- Build the full composition example first.
- Record concrete repetition or error-prone patterns in `scope`, `for_each`, and `presented` call sites.
- Try local helper functions or application-owned traits before changing tears.
- Measure compile errors, type inference, readability, and nested-composition cost.
- Distinguish local additive helpers from changes to public traits or combinator signatures.

## Acceptance criteria

- [ ] The composition example provides concrete evidence rather than a hypothetical API comparison.
- [ ] At least one application-scale composition is evaluated.
- [ ] The outcome is an explicit decision: keep the current API, add a local/additive helper, or propose an RFC amendment.
- [ ] Any new public trait, macro, composition law, or signature change is designed in an RFC and scheduled for a breaking minor release.
- [ ] The investigation preserves automatic scope application and subscription aggregation.