Decide whether a visualizer that turns available again gets a join trigger #26

Problem

PlayerStream returns a JOIN trigger when its client turns available again; VisualizerStream returns none, although its eligibility depends on availability. No comment says whether the asymmetry is intended. Their on_activation_written() bodies are also identical.

Evidence

Checked against the code at e69f3b46a801:

• PlayerStream::on_activation_written (player_stream.cpp:47-64) and VisualizerStream::on_activation_written (visualizer_stream.cpp:52-70) are textually near-identical: the same added/role_written_/state_since_activation_=false/JOIN logic, and the same drop of sent_, ledger_, cursor_ and announce_.
• PlayerStream::on_client_state returns JOIN when available turns true (first report, or after being unavailable) (player_stream.cpp:66-86). VisualizerStream::on_client_state just assigns available_ and has no state_received_ or was_available tracking (visualizer_stream.cpp:72-84).
• VisualizerStream::eligible() (visualizer_stream.h:130) does depend on available_, so a visualizer returning to available gets no JOIN trigger. Session::on_client_state (session.cpp:392-394) then queues the marker with kind nullopt. VisualizerStream::bind_cursor defaults pending_kind_ to GROUP, so startup_lead_us gives only join_min_us rather than the group lead (visualizer_stream.cpp:365-380). Neither the code nor docs/internals.md explains this asymmetry (grep found nothing).
• Session::on_activation_taken (session.cpp:801-806) calls artwork_ and source_role_ with role_active(string), and player_ and visualizer_ with roles.contains(StreamRole).

Checked and not part of this issue

• 'Line for line' is true only for on_activation_written, and not exactly there: the visualizer version also resets offset_ (visualizer_stream.cpp:64) and the player version does not (player_stream.cpp:56-62).
• prepare, announce_due, commit_announce, bind_cursor and cursor_ring are not line for line. VisualizerStream::prepare handles in-place configuration announcements, usable_wanted and on_stream_changed. PlayerStream::prepare handles follow_wanted and switch_ formats. Visualizer cursor_ring and ring_of are keyed by VisualizerConfig, and bind_cursor resets offset_ and uses its own startup_lead_us (visualizer_stream.cpp:365-380). Player bind_cursor uses the PlayerLead and InputKind (player_stream.cpp:482-488).
• set_support also differs: the player constructs Ledger(cap, true) and sets output_delay, the visualizer constructs Ledger(cap, false).
• ArtworkStream's 'returned' is not a drifted copy of the player logic. It clears left_ only when the client was previously received and unavailable (artwork_stream.cpp:63-67). That is the artwork role's own stream-lifecycle semantics (it has left_ and no cursor or trigger kind), so it is not comparable.
• Two role-identification schemes is a deliberate split, not drift. sched::StreamRole/RoleSet (sched/types.h:81-107) covers only the roles whose streams the cursors and markers carry (PLAYER, VISUALIZER) and is what the queues use (queues_.head_roles, roles_ahead, roles_written_). Artwork and source have separate stream objects with no cursor markers and use the string-based role_active (session.cpp:515, 801-802).

Direction

Decide (owner) whether the visualizer should trigger a join, then fix it or comment the asymmetry. Optionally share the identical activation code.

Done when

• The behavior is decided and either tested or commented at the asymmetric site.