Fix FastAPI benchmark: match baseline routing to fastapi-startkit

[tmgbedu]

Problem

The raw-FastAPI baseline (python/fastapi/server.py) registered routes with
direct @app.get/@app.post decorators, while the fastapi-startkit app
registers the same three routes via APIRouter + app.include_router(...).
On FastAPI 0.139, include_router keeps a nested _IncludedRouter node on
app.router.routes, adding a per-request resolution layer that flat
add_api_route registration doesn't pay. So the benchmark was measuring
include_router's routing cost, not fastapi-startkit's framework overhead.

Fix

Register the baseline's three routes on an APIRouter, mounted via
app.include_router(router) — the only remaining difference between the two
apps is now the framework itself.

Route behavior is unchanged and verified:

• GET / → 200, empty body
• GET /user/123 → 200, body 123
• POST /user → 200, empty body

Benchmark: before vs after

Method: Docker python:3.14-slim, uvicorn --workers=$(nproc) (11 workers),
oha 1.14 with keepalive + --latency-correction, 8s duration × 4 reps,
concurrency 64 and 256 — run twice per cell (once target-sequential, once
target-interleaved per rep, to average out host-load drift), 8 reps/cell
total. Matched stack both sides: FastAPI 0.139.0 / Starlette 1.3.1
(fastapi-startkit pinned to 0.47.0).

Relative delta (fastapi-startkit vs fastapi baseline; negative = startkit slower):

Route	Δ @ c64 before → after	Δ @ c256 before → after
GET /	−5.8% → −0.4%	−9.3% → +0.3%
GET /user/0	−11.7% → −1.0%	−6.3% → +8.4%
POST /user	−9.8% → +1.4%	−10.9% → −1.8%

Average delta across all 6 cells: −8.9% before → +1.1% after. The
framework-level overhead collapses to noise once both sides register routes
identically — confirming the prior gap was routing-mechanism cost
(include_router), not fastapi-startkit overhead.

Caveat: same-host macOS/OrbStack comparison, not official/authoritative
numbers (those require the Linux run.sh harness); host was under mixed
background load during measurement, hence the double run per cell.

[tmgbedu]

Post-merge review note (agent code-reviewer, task the-benchmarker#1036):

This PR was already merged (merge commit f75a843, merged_at 2026-07-15T19:27:04Z by @tmgbedu) before this review could be submitted — 0 reviews and 0 CI checks (statusCheckRollup) recorded prior to merge, despite .github/workflows/ci.yml being configured to run on pull_request.

Technical assessment performed post-hoc against the merged content on fastapi-starkit:

1. python/fastapi/server.py: routes now registered on APIRouter() and mounted via app.include_router(router). All 3 routes (GET /, GET /user/{id}, POST /user) preserved with identical handlers/behavior. Correct and matches the stated goal (match fastapi_startkit's include_router usage).
2. Diff scope: the PR's file list (vs its stale merge-base) also touched .gitignore, python/fastapi/config.yaml, python/fastapi_startkit/config.yaml, python/fastapi_startkit/pyproject.toml — but diffing PR head against the branch tip at merge time shows these were already identical (applied via earlier merged PRs #4/#9/etc.), so the actual merged delta was server.py only. No unrelated/corrupted content (no README changes).
3. Base branch: confirmed fastapi-starkit is this fork's actual default branch (fastapi-startkit/web-frameworks), not upstream the-benchmarker/web-frameworks. isCrossRepository=false.
4. Benchmark numbers in the PR description (avg delta -8.9% -> +1.1%) are self-reported/manual (no CI benchmark job ran); methodology is documented but unverified by automation.

No functional objections to the code change itself. Flagging the merge-without-review/CI as a process gap for the team, not a defect in the diff.