Authenticated event trigger must claim the requested ticket, not an arbitrary ready item

[tom-sapletta-com]

Problem

The Founder/coding flow can mark a concrete Planfile ticket ready, but starting subactor-coding-agent.service claims whichever queue item wins the ordinary scheduler. A user command therefore cannot guarantee immediate execution of the ticket it just created or resumed.

Live evidence on 2026-09-02:

• requested canary: PLF-11498
• POST /tickets/PLF-11498/ready committed (the client timed out after 20s, as observed previously)
• coding-agent service was started immediately
• first claim: PLF-11530, target ticket-318
• timer then started another cycle whose claim was PLF-11532
• PLF-11498 remained unexecuted despite the explicit request

This prevents event-driven chat autonomy and makes /ready insufficient as a command-to-operation boundary.

Required behavior

Provide an authenticated, auditable, single-use operation that makes a specific ready ticket the next claim for an authorized queue/handler. Bind the operation to ticket id, queue, handler, actor, lease id, expiry and correlation id. It must not bypass ticket policy, dependencies, retry limits or human boundaries. If the exact ticket cannot be claimed, return a typed blocker rather than silently claiming another ticket. Scheduled selection remains the recovery path only.

Acceptance

• An authenticated trigger for ticket A cannot result in ticket B being claimed by that invocation.
• Concurrent triggers are serialized and idempotent by correlation id.
• Expired/unauthorized triggers cannot affect queue ordering.
• Claim and terminal receipts are queryable by Founder Chat and Process Control.
• E2E test covers another higher-ranked ready item existing at trigger time.