docs(adr): reject a Django bootstrapper

[lesnik512]

Why

A 2026-09-07 survey assessed a dozen candidate frameworks against the five already supported. One survived — Taskiq, filed as #178. Django is the one rejection worth a record: it is the largest Python web framework, so its absence reads as an oversight rather than a decision, and the reason it does not fit is not visible from the code.

Design

Every bootstrapper keeps one contract — the user constructs the application, passes it in, and gets the same object back. Django's observability is conventionally owned by settings.py, which runs before any object a bootstrapper could be handed. ADR-0001 is the calibration: FastMCP was the hardest framework to fit and still had an application object to attach to.

The alternative that would fit — attaching to a constructed ASGIHandler, outside MIDDLEWARE — is recorded as rejected, and is what the revisit trigger names.

Non-goals

• Not a decision about Taskiq (Add a Taskiq bootstrapper #178), which lands or does not on its own merits.
• Not a decision about gRPC. An earlier revision of this PR carried an ADR rejecting gRPC on free-threading grounds. That argument was wrong and the ADR is gone: .github/workflows/_checks.yml already installs an explicit extras allowlist on the free-threaded leg and excludes orjson, otl and pyroscope, so a grpc extra would be a fourth entry in a mechanism that already exists — the same status the pyroscope instrument has today under pyroscope extra cannot install on free-threaded CPython #171. gRPC is assessed-but-not-scheduled, filed as an issue.
• No code, no extras, no test changes.

Verification

• Both the decision and its revisit trigger are single, matching the shape of the other eight ADRs.
• lychee --offline: no external URLs in the file. docs/adr/ is excluded from the published nav, so mkdocs --strict is unaffected.