Emit an app-lane business event into the project feed

The write twin of the feed read above (app-events-emit-lane): deployed app code records ITS OWN business facts — "signature completed", "booking created" — as ordinary feed rows with source: "app", class: "app", read back by every existing and future feed consumer with zero extra work. service_key ONLY, own-project (a cross-project key gets 403, never a 404 existence oracle); principals, grant keys, and admin keys are rejected in v1 — nothing platform-side should fabricate app facts. NOT lifecycle-gated (data-plane classification): a frozen/dormant organization's app keeps serving, so its facts keep recording — gating the emit would punch silent holes in the feed exactly when the owner is debugging. event_type must be flat snake_case matching ^[a-z][a-z0-9_]{2,63}$ and must not name platform-registered vocabulary (400 RESERVED_EVENT_TYPE — e.g. mailbox_suspended is off-limits), so an app can never impersonate a platform event; every consumer discriminates app rows from platform rows structurally on (source, event_type), not by naming convention. The response next_actions[] is ALWAYS the platform-synthesized poll entry, never app-supplied — an app payload that happens to contain a next_actions-shaped field is rendered as inert data, never as an instruction (agent-instruction-injection containment). Bounded by a per-tier eventsPerDay quota pooled across the organization's projects for the UTC day (prototype 1,000 / hobby 10,000 / team 100,000): once spent, 403 QUOTA_EXCEEDED with details: {resource: "events_per_day", scope, used, limit}. idempotency_key is durable resource identity (backs the (source, source_event_id) UNIQUE, namespaced per-project server-side), not transient header-based retry dedup — the same key always replays the ORIGINAL stored event with deduplicated: true instead of writing twice.