docs: add a tested Taskiq worker recipe built on FreeBootstrapper

[lesnik512]

Closes #274. A new integrations page for Taskiq workers, plus a test that runs the recipe. There is no change under lite_bootstrap/, and no new extras. The install-isolation and free-threaded CI lists are unchanged.

The recipe

The handlers fire on TaskiqEvents.WORKER_STARTUP and TaskiqEvents.WORKER_SHUTDOWN only.

• On startup: build FreeBootstrapper(FreeConfig(...)), call .bootstrap(), then TaskiqInstrumentor().instrument_broker(broker).
• On shutdown: call .teardown().

The bootstrapper is kept on TaskiqState instead of a module global. The brief only asked to register the handlers; I went further and also build the bootstrapper inside the startup handler. That way the client process never constructs one, so it gets no instrument-readiness or missing-dependency warnings.

The page also covers:

• why the client process is left to its web framework's bootstrapper;
• the install line, with otl-http for free-threaded workers;
• Taskiq's PrometheusMiddleware and its two side effects: the process-wide PROMETHEUS_MULTIPROC_DIR and its own HTTP server on server_port;
• Sentry.

Test

tests/test_taskiq_recipe.py registers the same handlers, with the same calls in the same order, on a taskiq.InMemoryBroker. It then runs the real broker.startup() / broker.shutdown(). InMemoryBroker fires the client and worker events in both, so the handlers are not called by hand.

It asserts that:

• after startup, the bootstrapper is bootstrapped and OpenTelemetryMiddleware is in broker.middlewares;
• running a task produces a PRODUCER span and a CONSUMER span on lite-bootstrap's TracerProvider;
• after shutdown, the bootstrapper is torn down.

As a mutation check, removing the instrument_broker call makes the test fail.

The brief also asked whether instrument_broker still works when called inside WORKER_STARTUP. It does. AsyncBroker.startup runs the event handlers before it walks self.middlewares for middleware startup, so the inserted middleware is in place in time.

taskiq[opentelemetry] goes in the dev group only. It resolves to 0.13.0, which requires Python >= 3.10, so every pytest leg can install it.

Verified outside the suite

• Sentry claim on the page. I checked it with a throwaway script, not in the suite. A task raising ValueError on an InMemoryBroker with a Sentry-configured FreeBootstrapper produced an error-level Sentry event from logger taskiq.receiver.receiver, carrying the ValueError.

Noticed in Taskiq, not acted on

instrument_broker inserts the middleware without calling set_broker. As a result, the middleware's worker CPU and memory observations, which check self.broker.is_worker_process, never report. Tracing and the task counters are unaffected. That would be an upstream Taskiq issue.

Checks

just lint-ci, just test-ci (341 passed, 100% coverage), just docs-build (strict), and just adr-check all pass.