Managers: a refused poll stops the process, and the manager is a conformance subject

[turbolytics]

Fixes #267.

The defect

Tumbling.Start logged a failed poll and polled again. A window the destination rejected was collected, written and refused every tick for as long as the process lived, and the container reported healthy throughout. Observed on 2026-09-12 against the live Bluesky firehose: three minutes, a failure every ten seconds, zero rows written, container Up.

The fix

• Start returns the first failed poll. The rows stay in the state table, because Poll deletes only after the sink accepted them, so a restart republishes the window. There is no retry in place: the sink ran its retry ladder before the error reached the manager, so what arrives is final.
• run treats a manager's error as the pipeline's. It cancels the consume loop through a WithCancelCause context, the loop drains as it would on SIGTERM, and the process exits with the manager's error rather than the loop's cancellation.

The manager as a conformance subject

The manager is its own kind in the registry, manager, beside pipeline. It is not a sink and not a handler: it collects, flushes and deletes, and the delete is its commit. Its invariants are the consume loop's checkpoint claims restated for that commit, plus the liveness a poll loop owes on its own:

Invariant	Class	Claim
manager.delete.after_flush	safety	The state table still holds every closed window when Flush runs, and none once the poll returns. Observed from inside the flush, not inferred from the count afterwards.
manager.delete.nothing_on_failure	safety	A failed flush deletes nothing.
manager.publish.eventually	liveness	The loop publishes a closed window on its own.
manager.failure.exits	liveness	A refused poll stops the loop after one attempt, with the rows still in the table.

internal/conformance/manager.go drives a ManagerSubject the way pipeline.go drives a PipelineSubject: the harness owns a recording sink, fails its flush on demand, and judges the event order and the state table. The tumbling manager's subject supplies build, seed and count in 40 lines. All four invariants are enforced: true.

The one unit test that pinned the old behavior, StartSurvivesAFailedPoll, is replaced by StartReturnsTheFirstFailedPoll.

Registry and generator

manager joins KINDS and INTEGRATION_KINDS in the generator, the registry tests expect five kinds, and docs/coverage/integrations/manager.tumbling_window.yml is constructed: false like the pipeline configurations. The page renders the manager column under checkpoint and lifecycle.

The status file for the new integration follows from CI's reports in a second commit, the way every new integration has landed.

Verification

Check	Result
go test -short -race ./...	clean
TestManagerTumblingWindow_Conformance	four cells proven
go vet, gofmt	clean
pytest tests/tooling	204 pass, page regenerated

Not in this PR

• The sqlcommand sink's errors are uncoded, so a refused flush exits 1, which errs.Retryable reports as retryable. A constraint violation is a user-fixable error and should exit 10. That is a classification change in the sink, and sink.error.classifies has no cell for any sink yet.
• A failed final poll at shutdown still only logs. Its rows are in memory and gone either way.
• The tumbling window docs on the site should say that a refused publish now stops the process. Separate PR.