feat(server): prune sessions past a configurable retention window

[otavio]

Part of the perf stack, now based on #6883 — #6886 left the stack and targets master on its
own. Two commits: migration 022, then the retention window itself (the follow-up fix for
head-of-line blocking is squashed into it, since the feature never shipped without it).

Closes shellhub-io/team#201 — that trailer cannot close a team issue from here, so the issue
needs closing by hand on merge.

Why

Nothing pruned sessions or session_events. On the instance this was measured on the oldest
session dated from 2023-06-05, and session_events alone was 4,517 MB across 6.7M rows — 76%
of the entire database. That is why the database does not fit in a sane shared_buffers, and
it is a data retention gap in its own right (see team#106, team#96).

What

Migration 022 — autovacuum. The default scale factors are proportions of the table, so the
bigger it gets the longer autovacuum waits: at 0.2, session_events gets no vacuum until ~1.3M
rows are dead, and at 0.1 no analyze until ~670k changes. It had gone 45 days without one,
leaving the planner estimating against stale statistics on the largest table in the database.
Lowered to 0.05/0.02, plus a one-off ANALYZE — the ALTERs only change when the daemon next
acts, so they do nothing about a backlog that already exists.

Retention cron. A nightly job deletes sessions started longer ago than the window,
cascading into their events.

• Off by default. The deletion is permanent and unattended, and the events are the
  recording, so an upgrade must not start discarding history on its own.
  docker-compose.enterprise.yml sets 180 days, where the retention commitment and the volume
  are both known.
• Batched, and capped at 100k sessions per run. An instance adopting this can have years to
  shed; draining that in one night is the write storm the batching exists to avoid, on a host
  already producing 104 GB of WAL a day. The backlog drains over successive nights instead,
  which also leaves an operator who did not want this time to notice.
• Active sessions are never pruned. closed is not usable for this — a session whose server
  died never gets closed and would otherwise be immortal — so the guard is an anti-join against
  active_sessions, which is what a live session actually holds.
• Recordings go before rows. A recording is an object keyed from the session UID with
  nothing in the schema pointing at it, so the row is the only thing that can still name it.
  Community has no object storage, so the pruner is a registered seam (like the firewall and
  license evaluators) that the cloud module fills in — see shellhub-io/cloud#2490.

Note for reviewers

findNonTransactionalStatement is anchored to the start of a statement. That is a prerequisite,
not a drive-by: unanchored, VACUUM matches inside autovacuum_vacuum_scale_factor and the
guard condemns an ALTER TABLE that is transactional in every respect. Every keyword in that
list is statement-initial, and the check is now per-statement, so it is strictly stronger.

Testing

• Store: list/delete pair covered for cutoff, ordering, limit, active-session exclusion and
  event cascade. Mutation-checked — flipping the ORDER BY and removing the anti-join each fail.
• Service: batching, the per-run cap, the disabled window, and that a failing recording prune
  leaves the rows alone.
• Migration: reloptions and last_analyze asserted on a migrated database.
• Full server suite (27 packages) and golangci-lint run ./... clean.