duckdb: reuse DatabaseInstance across iterations to fix harness throughput

[tc-agent]

Make the duckdb parse_fuzz_test harness usable for fuzzing again. This is a throughput / build fix, not a coverage push.

Problem

Since DuckDB landed its PEG-based parser, ParserCache has lived on the DatabaseInstance. The upstream harness constructs a fresh duckdb::DuckDB(nullptr) per iteration, which rebuilds the matcher tables from scratch on the first query of each fresh instance. Under ASan that rebuild costs tens of seconds. When a fuzz input hits the SimilarEntry → CreateDefaultEntries path it can exceed the libFuzzer -timeout=25 on the very first iteration; even when it doesn't, throughput stays near 0 exec/s.

Production runtime line coverage is 11.26% per Fuzz Introspector (48,402 / 429,990 — also visible in the coverage report), which is consistent with the fuzzer doing only a handful of executions before its timer expires.

What changes

1. Reuse one DatabaseInstance across iterations and prime the PEG matcher in LLVMFuzzerInitialize. LLVMFuzzerInitialize is not bounded by the per-input timeout, so the one-off matcher build no longer races the 25 s budget. Per-input cost drops from seconds to milliseconds; the harness reaches ~9 exec/s under ASan on a 4-core build (vs. effectively 0 today).

   The DatabaseInstance is shared across iterations, so catalog state (CREATE TABLE / CREATE INDEX / etc. that succeed) accumulates over the run. Each iteration uses a fresh Connection; the DatabaseInstance and any persisted catalog entries outlive it. This is called out in a comment on g_db.

2. Add -I./third_party/fmt/include to the harness compile so cast_helpers.hpp's #include "fmt/format.h" resolves. This matches the include_directories(third_party/fmt/include) already in CMakeLists.txt used for the in-tree CMake build of libduckdb_static.a; only the standalone harness compile was missing it. The last successful production build is recorded at OSS-Fuzz (last_successful_build.finish_time = 2026-05-28T07:28:50Z); the include is preventive against the same surface breaking in a future build.

Note on the harness file

projects/duckdb/harnesses/parse_fuzz_test.cpp shadows the upstream copy at test/ossfuzz/parse_fuzz_test.cpp; build.sh overlays it onto the source tree before compiling so the matcher-reuse change is applied without waiting for an upstream round-trip. The same fix is tracked upstream at tc-agent/duckdb#1; the overlay can be retired from build.sh once that lands.

This PR intentionally does not change harness coverage scope. Follow-up work to add CSV/JSON and Parquet harnesses + seed corpus generation will go in a separate PR.

[github-actions]

Fuzzing Coverage Report

Tested: project duckdb · base 3fa060f → head f56bf25 · 300s total fuzz budget · updated 2026-05-28 19:00 UTC · workflow run

OSS-Fuzz: Fuzz Introspector · build status

Metric	Before	After	Delta
Static reachability	>45m	>45m	—
Line coverage	0%	10.3% (38206/372106)	new
Branch coverage	0%	7.9% (12335/155597)	new
Function coverage	0%	14.6% (5004/34290)	new

Per-harness

Harness	Lines before	Lines after	Δ
parse_fuzz_test	0%	10.3% (38206/372106)	new

_{Δ = (after − before) / before, to accommodate that denominators may change. "new" when before is 0; "deleted" when after is 0.}