docs: framework guides section + document x-nav-order

[oreofeolurin]

What & why

Adds a Guides tab to site/ with framework-specific walkthroughs, and documents the x-nav-order extension that landed in #21.

Every guide follows the same six-step spine, so a reader can skim across frameworks and a new one slots in without inventing a shape:

1. Emit the document into api/openapi.json as a build step
2. Tags become resources (including nested store/orders tags)
3. Order the sidebar with x-nav-order
4. Document events with x-events
5. Replace generated code samples with x-codeSamples
6. Gotchas — the framework-specific traps

Page	Covers
/guides	The contract — four extensions plus tags — and a post-process recipe for frameworks with no clean annotation hook
/guides/nestjs	@nestjs/swagger, @ApiTags, @ApiExtension, snapshotting createDocument()
/guides/fastapi	openapi_extra, native 3.1 webhooks, dumping app.openapi()
/guides/spring-boot	springdoc, @Extension / @ExtensionProperty, the parseValue trap
/guides/hono-zod-openapi	Extensions inline in createRoute, getOpenAPI31Document()

/openapi gains a Sidebar order section for x-nav-order, with a ### Why not just reorder the document? subsection. That framing matters — "reorder the spec" is the obvious objection, and it doesn't hold for the two cases people actually hit:

• normalize reads verbs off a fixed METHODS array, so two operations sharing a path item always come out GET before POST regardless of document order. Putting Create account above List accounts is impossible without the extension.
• Generated documents get regenerated. NestJS, FastAPI and springdoc all derive path order from handler declaration order, so hand-sorting the emitted JSON is wiped on the next build.

Every framework API used here was checked against the actual source rather than from memory — @ApiExtension accepts any value and merges across repeated calls, @ExtensionProperty.parseValue() defaults to false (so value = "1" emits a string that Markline's typeof === "number" check silently drops), and zod-to-openapi spreads unknown route-config keys straight onto the operation.

Also fixed, while in these files

• Four /openapi TOC ids pointed at anchors that don't exist (playground → the-playground, events → events-webhooks, overlays → mdx-overlays, ai-and-actions → ai-page-actions), so those sidebar links scrolled nowhere. Same for a /versions#api-reference link.
• The @ApiExtension note in the events section claimed an object value is required. It isn't — only the x- key prefix is enforced, and repeated calls merge, which is what lets x-events and x-nav-order sit on the same handler.
• build-search.mjs walked only the first non-OpenAPI tab when grouping llms.txt, so a second content tab's pages fell into the ungrouped "More" bucket. It now walks every content tab and qualifies group titles when there's more than one (Guides · Python). This also improves any consumer site with more than one docs tab.

Checklist

• npm run typecheck passes
• npm run build passes — 30/30 static pages
• Docs/README updated if behavior or config changed

Also verified: all 6 pages render every section, all 16 internal links and anchors resolve, and the guides reach the sitemap, llms.txt and the Pagefind index.