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

[otavio]

Rebased onto master. This no longer sits on #6883, which now lands after it — the rest of the
perf stack has gone the same way (#6886 already targets master on its own). Two commits:
migration 019, 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 019 — 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

Two things arrive here that used to come from #6883, because the rebase moved this PR in front
of it.

TestNonTransactionalMigrations guards the two conditions a statement PostgreSQL refuses inside
a transaction needs, neither of them visible in the SQL: bun decides transactionality from the
.tx. filename suffix, and the pool runs in pgx simple-protocol mode, where a multi-statement
Exec is itself an implicit transaction block. Nothing in this PR needs the exemption — 019 is
transactional throughout — but the guard has to exist before the first migration that does, and
#6883 brings that migration.

The match is anchored to the start of a statement rather than searched for anywhere in the chunk.
That is a prerequisite, not a drive-by: unanchored, VACUUM is also a substring of
autovacuum_vacuum_scale_factor, so the guard would condemn the ALTER TABLE in 019, which is
transactional in every respect. Every keyword in the list is statement-initial, and the check is
per-statement, so it is strictly stronger than a substring search.

#6883 carries the identical file, so whichever lands first the other rebases without a conflict.

One rebase fix worth naming: master has since grown its own fixedClock/pinClock in
storetest/helpers.go, so session_tests.go uses those instead of declaring a second copy.

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.
• Re-verified after the rebase onto master: ./api/store/... and ./api/services/... green,
  go build/go vet clean, golangci-lint run ./... reports 0 issues.