Publish a permanent page from ONE answer your AgentDesk already gave.

AGENTDESK-RD(c1), Will's directive 2026-08-07: "in all the answers we need the ability to create a permanent page for the question". POST /answer-pages/{id}/pin publishes an answer page that ALREADY EXISTS, and answer pages only come into existence when an agent fetches a question-shaped URL — so a conversation turn (and every Sandbox turn) had no route to a page. This is that route, and it ends in the SAME _pin_answer_page_row the pin uses, which is what keeps the published-pages billing sync on one path.

── THE THREE OUTCOMES FOR A QUESTION THAT ALREADY HAS A PAGE ───────────────

An answer page is addressed by (domain, slug) and the slug is derived from the question, so "does this answer already have a page" is a question about the slug, and the three answers are genuinely different:

• a pinned page at that slug → 409. The question already has a published page; publishing a second one at an adjusted slug would split the same question across two URLs and bill for both.
• an ephemeral page at that slug → that row is PINNED. It is the row the desk already serves this question at, so publishing it is what the owner asked for; minting a second row would leave the served URL unpublished. (Its stored answer stays as-is — the stored answer IS what the URL serves, and overwriting it here would publish text no agent has ever been given.)
• nothing at that slug → a new row, at a slug from _allocate_answer_page_slug (a rejected row can be squatting it).

The new row's llm_* columns are copied from the ASSISTANT MESSAGE, because that is what generating this answer actually cost — the same aggregate the answer-page lane stamps at generation, so cost-per-page stays a real number rather than a NULL that averages in as free. fetch_count is 0: no agent has fetched this URL, and starting it at the generated-page default of 1 would claim a fetch that never happened (and, at 2, would make the Desk feed call it repeat demand).