[Feature]: Promote server to Stable — freeze the ctx/app API and define exit criteria #131

Pre-flight checklist

• I searched existing issues and did not find a duplicate request.
• I explained the problem or use case, not just the desired API.

Problem or use case
server is Experimental and very young: it was introduced in 1.11.0, and a large slice of its request/response surface (ctx.body, ctx.cookies, ctx.setCookie, ctx.accepts, ctx.stream, ctx.sse, ctx.renderStream, ctx.renderResponse, and app.listen()) only landed in 1.14.0. A backend framework whose ctx shape changed materially one minor ago cannot be depended on for services. There is no published bar for what makes server stable.

Proposed solution
Publish exit criteria and freeze the ctx and app contracts for at least one minor cycle. Criteria: (a) frozen ctx/app surface with a documented request lifecycle; (b) test coverage across routing, streaming, SSE, cookies, and content negotiation; (c) the session/middleware primitives in #132 landed; (d) integration with file-based routing (#149) at least at the bridge level; (e) a documented per-runtime support matrix. Tracking issue for the server promotion.

Possible API or UX shape

## Stability: targeting Stable in 1.15.0
Frozen surface: createApp/app.use/app.route/app.listen, ctx.{req,res,params,
query,body,cookies,setCookie,accepts,stream,sse,renderStream,renderResponse}
Exit criteria:
- [ ] ctx/app frozen for one minor
- [ ] session + middleware primitives (#132)
- [ ] file-based routing bridge (#149)
- [ ] per-runtime support matrix (Node ≥ 24, Bun, Deno, edge)

Alternatives considered
Positioning server as "experimental, use Express/Hono in production" — concedes the "dependency-free backend" differentiator that is one of the few things bQuery offers over client-only frameworks. Promoting without the session/middleware story (#132) — premature, since real services need both.

Relevant area
server

Additional context
bQuery's server is one of its genuine differentiators versus React/Vue/Svelte (which lean on separate backends), so stabilizing it is high-leverage. Must stay zero-dependency.