feat(postgres): expose PostgreSQL tunables as SHELLHUB_POSTGRES_* variables

[otavio]

Top of the perf stack — based on perf/identity-resolution-statements (#6890), itself on
#6888 → #6886 → #6883. Merge those first; this then targets master on its own.

Every ShellHub deployment inherits the same untuned postgres:18.0: 128 MB of
shared_buffers regardless of the machine underneath. On the largest managed instance that is
a 84.76% buffer cache hit ratio against a 5.9 GB database on a 15.6 GB host.

This PR does not tune anything. It ships the seam, with every default equal to the value the
deployment already runs with, so the rendered command line is unchanged. The values are set
per host — for the managed fleet, in shellhub-io/shellhub-managed-deploy#400, which derives them
from /proc/meminfo.

Why env vars and not a second Compose file

The obvious alternative is for a deployment to override command: in its own overlay. That
breaks quietly: Compose replaces command: rather than merging it, so an override has to
restate io_method, wal_compression and shared_preload_libraries — and silently drops
whatever this list grows next. #6883 and #6886 each added a flag here in the last week, so that
is not hypothetical.

bin/docker-compose already chains COMPOSE_ENV_FILES with .env.override last, so
interpolation is a seam both community users and managed hosts already have.

:- rather than - throughout: an override that sets a key to nothing must fall back, not
expand to -c shared_buffers=, which postgres refuses to start on.

What is exposed

	default	note
shared_buffers, max_wal_size, min_wal_size, max_connections	128MB, 1GB, 80MB, 100	written by initdb; this file is now their source
effective_cache_size, work_mem, maintenance_work_mem	4GB, 4MB, 64MB	PG defaults
checkpoint_timeout, random_page_cost	5min, 4	PG defaults
effective_io_concurrency	16	PG18 raised this from 1; the default is deliberately not the old value
wal_compression	lz4	as set by #6883, not PG's off

checkpoint_completion_target is not exposed: it has defaulted to 0.9 since PG14, so
setting it is a no-op. Verified against the running image rather than assumed.

Two Docker-side knobs come along because they bound the same thing:

• shm_size — parallel-query segments are allocated from /dev/shm, which is 64 MB by
  default. shared_buffers is not (shared_memory_type is mmap), so this tracks work_mem
  and parallelism instead.
• mem_limit — stays at today's unlimited (0, which Compose normalises away entirely), but
  is worth setting once shared_buffers grows on a host with no swap, where an OOM is a hard
  kill.

Testing

• ./bin/docker-compose config renders and shlex-splits the folded scalar into correct argv, at
  defaults and under override.
• An empty override falls back rather than emitting a bare -c shared_buffers=.
• A throwaway postgres:18.0 booted with a fully tuned command line reports all twelve settings
  with source = command line — confirming they override the initdb-written postgresql.conf —
  and pg_stat_statements still loads alongside.
• Rendered with the exact environment a 15.6 GB managed host produces, end to end.

Refs shellhub-io/team#198.

[otavio]

Superseded by #6886, which now carries this work rebased onto master.

The shape changed on the way over. Instead of thirteen SHELLHUB_POSTGRES_* variables, one
SHELLHUB_POSTGRES_EXTRA_ARGS is appended to the postgres command line, and sizing lives in the
managed deploy and the cluster rather than in .env.

The reasoning that led there: the wholesale-replacement problem this PR set out to solve is
specific to command: — shm_size and mem_limit merge from an override file the ordinary way
(confirmed, 64m → 1g), so they did not need a seam at all. And since postgres takes the final
occurrence of a setting, appending is enough to outrank the in-repo flags rather than having to
parameterise each one: a deployment can raise shared_buffers or override io_method without
naming the flags it does not care about, and a flag added to the repo later cannot break an
existing override.

One behavioural difference worth recording: this PR defaulted wal_compression to lz4, which
came from #6883's WAL commit rather than from PostgreSQL. On a master base that would have been
a silent behaviour change smuggled in under a "no behaviour of its own" parameterisation, so it is
not in #6886 — a deployment that wants it appends -c wal_compression=lz4.

No commits are lost; perf/postgres-tunables stays as-is for reference.