Keep long-running tasks from going stale

[snopoke]

Tasks with a stale_timeout go stale unless something updates them, so today a long-running Celery or Procrastinate task has to ping itself from the task body. heartbeat_interval makes the worker do it — settable on the system integration, on the task, or per call.

Design decisions the diff doesn't show:

• One daemon thread per worker process pings every in-flight task, rather than a thread per task. It's started lazily at task_prerun, so publishers never get one, and a forked prefork child builds its own (an inherited thread reports is_alive() == False).
• The interval is resolved wherever the task is created — publish handler, or _maybe_create_task for eager/canvas tasks — so it always matches the stale_timeout it's protecting, instead of a worker inventing an interval for a timeout that was never set.
• stale_timeout defaults to 2 × interval, the same ratio taskbadger run already uses.

Worth a closer look:

• exit_session ownership (a23ada4). f8ea1cf fixed a session leak for eager tasks but made them close a session they never opened — an eager task inside a caller's with taskbadger.Session(): popped the caller's frame, so the caller's __exit__ raised IndexError. The handlers now mark the request when they open the session. Those two commits are worth squashing if you'd rather the series bisect clean.
• _taskbadger_system timing (4f4496c). It's now set before the idempotency return, so a @tracked task registered before ProcrastinateSystemIntegration(...) inherits the system's options. That also restores the record_task_args inheritance track()'s docstring already promises — a behaviour change to existing functionality, deliberate.

Both integration tests were verified to fail with Heartbeat.start stubbed to a no-op, so they aren't vacuous passes. They ran against the real API with local Redis and Postgres (7 passed).

Unrelated, noticed while testing: the Celery suite uses Redis DB 0, so messages from any other project on the same box can make the worker thread snapshot an unconfigured Badger before _bind_settings runs and fail a handful of pre-existing tests. Pinning celery_config to a dedicated DB would fix it; left alone here.