deps: update psycopg2-binary requirement from >=2.9 to >=2.9.12 - #24

Repo had 3 open dependabot PRs sitting unmerged (#22 github-actions bump,
#23 ruff bump, #24 psycopg2-binary bump) despite CI already running green
on all of them -- nothing was wired to actually merge them.

Enabled `allow_auto_merge` at the repo level (was false) and added a
workflow that: parses the PR title's "from X.Y.Z to A.B.C" version pair,
and for same-major (minor/patch) bumps calls `gh pr merge --auto --squash`.
A major-version bump, or a title GitHub's own bump-PR format doesn't match,
is left for manual review -- dependabot can't assess whether a major bump
is actually safe.

Deliberately `pull_request` (not `pull_request_target`) and a
`user.login`-based bot check (not the spoofable `github.actor`) -- every
dependabot branch lives in this repo, never a fork, so pull_request_target's
fork-secrets-exposure surface buys nothing here; zizmor confirms 0 findings.

Deliberately no branch-protection required-checks rule added: this repo's
established workflow allows direct pushes to master, and required-checks
would block that. GitHub's native auto-merge already waits for every
check currently running on the PR to succeed before merging, so it gates
on CI without touching branch protection.

Verified: yamllint clean, actionlint clean, zizmor 0 findings (was 2 high
before switching off pull_request_target + the actor check).

Every one of these was measured by the pip-audit-over-the-lock job added earlier this round, and none of
them was visible before it: pip-audit ran only in the advisory bundle, over the developer's INSTALLED
environment rather than what the project declares, and its output was nobody's assigned reading.

  aiohttp   >=3.14.1 -> >=3.14.3   PYSEC-2026-3545, -3546, -3547
  tornado   >=6.5.7  -> >=6.5.8    GHSA-wwv5-g3v4-889x, GHSA-8423-8fgw-73vq, CVE-2026-82397

psycopg2-binary's floor moves >=2.9 -> >=2.9.12 in the same pass. That one is not a security fix; it is a
floor that had drifted far enough to assert nothing.

The lock diff is three specifier lines and no resolved version at all: every one of these was already
resolving above the old floor, so the change closes the gap between what the project CLAIMS to support and
what it actually installs, without moving a single package. That is the whole point of a floor -- it is a
promise to users on older environments, and an unverified promise is what these had become.

These three changes are what dependabot PRs #27, #24 and #32 carry. They are applied here rather than by
merging those PRs because the PRs cannot land as they are: their checks belong to the August matrix (eight
shards, Python 3.10-3.12) that no longer exists, their heads are far behind master, and auto-merge is not
enabled on them. Updating them needs a `@dependabot rebase` comment, which is not mine to post. They will
close themselves as superseded on dependabot's next run.

There is also a reason not to merge them even if they could land: they were opened under the `pip`
ecosystem, which does not know uv.lock exists. Merging one would change pyproject.toml and leave the lock
describing the previous graph -- failing the `uv lock --check` gate immediately. That is exactly why the
ecosystem moved to `uv` earlier in this round; from now on a bump and its lock arrive together.