v26.09.26 — a failed start exits cleanly, and a clean stop releases the cache

A reliability release: flAPI now reports a failed start honestly instead of crashing or claiming success, and a clean shutdown really does release its cache.

Behaviour changes to know before upgrading

• A server that fails to start now exits 1. A port already in use used to log the error and then exit 0, so systemd would not restart it and a Kubernetes container showed Completed. Anything that treats exit 0 as "started" will see the difference — that is the point.
• heartbeat.params now takes effect. They were documented but never passed to the template. If you set them, your heartbeats start using them.

Fixed: a startup failure now exits non-zero instead of dumping core, or lying

Two startup failures were reported wrongly, and both matter to whatever supervises flAPI.

A database that cannot be opened — most often the DuckLake or DuckDB cache file still locked by
the previous process during a restart — used to abort: exit 134 (SIGABRT) with a core dump
of the ~77 MB binary. A crash-looping container filled its disk with core dumps of a recoverable,
operator-fixable condition. It now logs the reason and exits 1:

[error] Database initialization error: Error creating database, Details: Failed to attach
        DuckLake catalog: ... Could not set lock on file ".../cache.ducklake":
        Conflicting lock is held in .../flapi (PID 3534350) by user jr.
[error] flAPI cannot start until the database can be opened.

Other shapes that land here: an unreadable duckdb.db_path, a cache file on a volume that has
not mounted yet, bad attach credentials.

A bind failure now exits 1 as well, where it used to exit 0. the server could not start: bind: Address already in use was logged and the process then reported success, so systemd would
not restart it and a Kubernetes container went Completed rather than CrashLoopBackOff — the
reason visible only to whoever read the logs.

Genuinely unexpected exceptions still abort, which is what the handler is for.

Fixed: a clean shutdown now releases DuckLake and flushes the database

On SIGTERM, flAPI is meant to detach the DuckLake catalog and checkpoint the database before
exiting, so the next process can take the cache lock straight away and starts from a flushed file.
That work used to run in a place where it could not be relied on: it never appeared in a real
shutdown log, and on a failed startup the same code crashed. It now runs while flAPI is still
fully alive — after in-flight requests have drained — and says so:

[info] Received SIGTERM, shutting down...
[info] Detached DuckLake catalog: cache
[info] Checkpointed database

Long-running MCP tasks still executing at SIGTERM do not delay this: they are interrupted,
and the process exits promptly.

Fixed: heartbeat.params now reaches the template

An endpoint's heartbeat: block has always accepted params, and the configuration reference
documented them, but they were never passed on — every heartbeat ran the template with no
parameters. They now arrive exactly like request parameters:

heartbeat:
  enabled: true
  params:
    status: active       # the warm-up renders {{params.status}} as "active"

If you set heartbeat.params, your heartbeats will start using them. A heartbeat still runs
the endpoint's full request path — template, validators and query — whether or not the endpoint
is cached.