Create Landing Page Agent Session

Open a short-lived edit session against one landing page.

Returns an edit_session id to pass to the two routes above. The session is a LOCATOR, not a credential: it selects which draft the following calls act on, and get_api_user still authenticates every one of them. It carries a TTL and is bound at creation to this org and this actor.

actor_email is str(user.id), byte-identical to what the read and patch routes pass to require_edit_session. That is what closes the loop: a session minted here resolves for the same key that minted it, and a mismatch would make every subsequent call 404 against a session that plainly exists.

NO OWNABILITY GUARD, unlike the agent routes. agent_router refuses a write from a key whose actor_identities() is empty, because an org key authenticates as the shared constant api-key@graph8.com. The same constant lands in actor_email here, so two org keys in ONE org can read and patch each other's sessions. That is deliberate parity rather than an oversight: the two sibling routes already bind on str(user.id) and already accept org keys, so guarding only the create half would break the loop for exactly the keys the other half still serves. The boundary that matters is unchanged -- require_edit_session rejects a session from another ORG. Tightening all three together belongs with the per-key identity work recorded in .claude/agent-context/agent-runtime-api-key-door.md.

NOT SCOPE-GATED LOCALLY, unlike its two siblings, and that is deliberate rather than an oversight. They call require_scope("landing-pages:..."), which makes build_scope_policy record them as exempt; an exempt route publishes no x-graph8-scope, so their requirement is real but invisible in the contract -- and landing-pages is not a resource in scope_vocabulary.json at all, so the scope they name cannot be granted to a key. It is inert today only because require_scope runs in soak mode by default. Leaving this route ungated puts it in the GOVERNED set, where apply_scope_policy attaches the gate and the bundle publishes integrations:write -- the resource this file is actually mapped to. The siblings are left alone here: correcting them moves two published operations and belongs in its own change.