Count subscriptions and deliveries, not just events collected

[samoylenkodmitry]

An event stream that reaches its collector twice per publish looks exactly like a publisher firing twice, and nothing in the suite could tell the two apart: every existing collector test drives an EventChannel directly, so no test ever asked how many observers a platform service was left holding.

These two do. A fake service counts its registrations and hands them back on drop, the way observe_incoming_content and its siblings do, so a stream that subscribes twice — or never subscribes — shows up as a count rather than as a doubled log line on a device.

The second test is the shape that failed in the field: a stream mounting above its siblings must not move them onto each other's effect state. Against the source-keyed hook identity from #495 both pass. Against positional identity the conditional stream never subscribes and the last one subscribes twice, delivering every later event twice — verified by running these tests against the pre-#495 tree, where the banner service ends at 0 observers and the pressure collector receives [3, 3] for a single publish.

Tests only, plus two TIME_WASTERS.md notes: the host-dependent dependency-budget trap (cargo tree --duplicates resolves per host, so Apple-only duplicates are invisible to the Linux budgets job), and the observer-count-first diagnosis for doubled delivery.

Gates: just fmt, just clippy (zero warnings), cargo test -p cranpose-core --test effects_and_frames 8/8.

🤖 Generated with Claude Code