feat(seo): add AI agent runtime guide

[lilyshen0722]

Summary

• add the static and SPA-visible AI agent runtime guide at /guides/what-is-an-ai-agent-runtime/
• add the guides-hub card, sitemap route, Article/WebPage metadata, and four approved reciprocal links
• cover generator ordering, runtime-token placeholders, and direct SPA route rendering

Verification

• static SEO generator test
• direct V2 guide-route test
• TypeScript typecheck
• production build and generated artifact checks
• full frontend suite: 86 suites / 490 tests

Release readiness

Ready with follow-ups: additive static/SPA content only; no migration or runtime permission change. Rollback is a revert. CI must be green before merge.

[lilyshen0722]

Gated at 506533c3. Third guide carrying the same two non-existent event types. The routes and the ack contract are correct; the event table is not.

Verified real:

• GET /api/agents/runtime/events — backend/routes/agentsRuntime.ts:447, mounted at server.ts:218.
• POST /api/agents/runtime/events/:id/ack — agentsRuntime.ts:1157.
• "If a polled event supplies payload.deliveryId, the acknowledgement must echo that exact value." — exactly the implemented contract at agentsRuntime.ts:1115–1145, including the isDeliveryNonceRequired gate and the ADR-026 D6 behaviour.
• "do not confuse delivery with outcome" — correct, and a genuinely useful thing to tell a runtime author.

The event table repeats #1391 for the third time.

["task.assigned",     "A task was assigned to that agent."]
["integration.event", "An external integration produced an input with a source and data payload."]

integration.event has no producer anywhere in the repo — the real type is integration.summary (agentEventService.ts:351). task.assigned is an AgentRun.trigger value (models/AgentRun.ts:116, nativeRuntimeService.ts:609), not an AgentEvent.type; nothing constructs an event with it. Same two rows as #1388 and #1393, tracked in #1391.

This instance is worse than #1393's, and the difference is worth being precise about. The lead-in hedges — "Commonly documents these event categories" — which is true. But the table's own header is "What it means for a runtime", and the rows are written as runtime semantics: "A task was assigned to that agent", "An external integration produced an input." A runtime author reading this table will poll GET /events expecting two types that will never arrive. The hedge sits one line above a table that reads as the runtime's event vocabulary, so it does not do the work it appears to do.

chat.mention, thread.mention and heartbeat are all real, so three of five rows are correct — which is precisely what makes the other two costly here. This is the guide a runtime author reads first.

Suggested fix, consistent with #1391: integration.event → integration.summary; drop task.assigned or move it to a separately-labelled "run triggers" list; consider adding message.posted, which has 6 producers and is the entire wake-on-message path yet appears in none of the four guides.

Mechanical: all 29 pages rendered — 0 [object Object], 0 stray undefined, no token-shaped strings. node --test scripts/generate-seo-pages.test.mjs 2/2 on Node 22. Base is current main (0 behind). Most checks still pending at review time; Detect secrets, Source changed ⇒ version bumped and Stale-base merge guard have passed.

Process note rather than a code note: three PRs have now shipped or proposed these two rows, each independently, each with a green string-presence test. That is not three authors making the same mistake — it is one wrong docs-site/ entry being read three times. The fix that ends it is upstream in docs-site/agents/events.mdx, plus a guard that resolves documented identifiers against their producers. Both are in #1391.