GTM API / Append mass-action items

Feed more leads into a run already going, without a second preview or token: they run the approved plan and join the pacing chain BEHIND the tail. Identities are payload-kind leads, as a targets-scope create takes them: at least one of ln_member_id (the member NUMBER), ln_id / sn_id / profile_id (a URN), company_ln_id or nickname (a slug). A lead already enrolled comes back in skipped_duplicate_count, not run twice (dedup by member id). Up to 100 per call; repeat to keep a standing run fed. The run has to be live and payload-addressed (scope targets or none). Held for a spent limit (limit_reached) it still takes leads, which wait with it; paused otherwise, or stopped, it is 409 run_not_active, context.reason_detail saying which (canary_failed: retry the canary and release the gate, or start a new run). A generate run (step 1 is a creates: verb) is 422 run_not_payload_addressed: each lead would provision one more paid browser than consented to; an objects run is 422 too. The canary gate still applies. Contract: - MCP tool append_mass_action_items, registry package mcp.orchestration/mass_actions, mount orchestration.mass_actions. - Operation action, response envelope action. - Flags: none.