Link DuckDB statically and retire the self-extracting launcher (#78)

[jrosskopf]

Closes #78.

CI is green on Linux and Windows (34m49s — Windows compiles DuckDB from
source). One Windows fix was needed: duckdb/CMakeLists.txt sets
CMAKE_MSVC_RUNTIME_LIBRARY unconditionally as a plain variable, so /MT wins
inside its own subdirectory and cannot be overridden from here — mixing it with
our /MD gave LNK2038 for every DuckDB object. The x64-windows-static-md
triplet existed to match the prebuilt DuckDB DLL, which no longer exists, so the
build now uses x64-windows-static. A fully static CRT is also one fewer thing
the target machine needs. Same resolution flapi reached.

What

The launcher existed to put libraries next to the server. After #70/#76 that set
was down to one — libduckdb — so linking it in leaves the launcher with nothing
to do. The shipped artefact is now simply the server.

Gone: launcher/, scripts/bundle.sh, scripts/bundle.ps1,
scripts/stage_runtime.sh, the tar payload, the footer, the first-run unpack of
~84 MB into /tmp, and the per-version temp directories that accumulated there.
Net −515 lines.

DuckDB now comes from a pinned duckdb/ submodule at v1.5.5, built from
source. The prebuilt libduckdb_static.a cannot be linked at all: it leaves
ExtensionHelper::LoadAllExtensions undefined inside the archive. flapi solved
this first and this follows it.

Five traps, each found by something failing

• Not dummy_static_extension_loader. That target is for the prebuilt
  archive. Here duckdb_generated_extension_loader is what registers the
  statically linked extensions; linking the dummy instead satisfies the loader
  symbol with a no-op, so extensions compile in and never register — surfacing as
  58 unit tests failing on icu operators, naming nothing about extensions.
• An explicit extension set (core_functions, parquet, icu, json, autocomplete). A bare source build links only the first two; the prebuilt
  libduckdb we shipped before carried the rest.
• BUILD_UNITTESTS OFF. Not merely slow: with it ON, DuckDB exposes
  internals that are private in a normal build, so code compiles against members
  it has no business touching and breaks the moment the flag flips.
• DUCKDB_EXPLICIT_VERSION. DuckDB derives its version from git describe,
  which in a shallow submodule clone yields v1.6.0-dev82307 for a checkout
  sitting exactly on a release tag — and that string selects the extension
  repository.
• v1.5.5, not v1.5.4. At the v1.5.4 tag the in-tree headers disagree with
  DuckDB's own released amalgamation of the same version (private members,
  Identifier rather than string), and its prebuilt httpfs segfaults inside
  LoadInternal when loaded into a source-built engine. v1.5.5 is self-consistent,
  needs no source changes, and is what flapi already runs. src/ is untouched
  by this PR.

Runtime extensions still work

This was the open question, and the answer is yes: autoload and autoinstall stay
on, and the two quack tests — which install a prebuilt extension into the
statically linked engine — pass.

ENABLE_EXPORTS is set on the server target. Measured: httpfs and quack both
load correctly without it, so it is not load-bearing for what erpl-rev uses
today. It is kept because flapi, which loads its whole extension set as prebuilt
binaries, does need it — and an extension that does resolve host symbols fails as
a segfault inside its own LoadInternal, which reads as a broken extension
rather than a missing link flag.

Verification (Linux)

Check	Result
unit tests	16567 assertions, 107 cases, zero skipped
quack (prebuilt extension into static engine)	passes
ldd	no libduckdb
--smoke	reports v1.5.5
scripts/e2e.sh	13/13
doctor against A4H from the static binary	Ready
build cost	~2 min wall on 32 cores (46 min CPU)

Binary is ~86 MB, against 11.8 MB + a 67 MB libduckdb before — the same total,
as #78 predicted. Size was never the argument; simplicity is.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}