[Bug]: DuckDB post-query processing hang in Evidence sources run

[Etumos]

Describe the bug

The evidence sources command hangs indefinitely after completing source
evaluation. The "Evaluated sources, saving manifest" and "Done!" markers
print, then the process sits alive but produces no further output.

Symptom timeline of a single run:

[INFO]: Loading sources
... per-source evaluation progresses normally ...
[INFO]: Evaluated sources, saving manifest
[INFO]: Done!
<hang — no further output, no exit>

During the hang:

• Node process stays alive, sleeping (state Sl on Linux)
• Resident memory ~500 MB, low CPU
• No outbound database queries
• No file writes detectable in the project directory

The hang persists indefinitely. Manual interrupt or external kill is the
only way to end it.

Hypothesis: DuckDB inside the Evidence subprocess inherits all-available-
cores as its thread count. The post-query work (parquet finalization,
manifest save, or DuckDB internal cleanup) appears to stall on its own
thread pool. DuckDB's own performance docs recommend threads = 1 for
embedded use cases where multi-core contention can dominate at small data
scales.

We can't find a documented way to set DuckDB pragmas (threads, memory
limit, etc.) through Evidence's source/datasource config. If there is a
way, please point us at it.

If there isn't, would the Evidence team consider exposing DuckDB session
options through datasource config — e.g., a passthrough block like
duckdb: { threads: 1 } in the source YAML?

Not submitting a PR — filing for guidance and triage first.

Steps to Reproduce

We have not yet extracted a minimal standalone reproduction. In our
project the hang surfaces consistently (not flaky) under these conditions:

• Evidence project with ~60-80 sources
• Sources organized into 4 batches via the --queries flag
• DuckDB-backed datasource pointed at PostgreSQL
• Source SQL doing aggregation + joins, producing parquet outputs in the
  range of a few hundred KB to a few MB each
• Invocation:
  npm run sources -- --sources analytics --queries q1,q2,...,q17

The hang reproduces in two configurations:

• 4 parallel evidence sources subprocesses running concurrently
• 1 single subprocess running alone (sequential mode)

The second case is the more interesting one — a single subprocess on a
quiet machine still hangs in the same way. This suggests the issue is
not cross-process contention but something inside a single Evidence
subprocess's post-query path.

We are happy to engineer a minimal standalone repro, but would benefit
from rough guidance first on which inputs to target (source count, query
size, output size, etc.) — the bisection space is large.

Logs

[INFO]:    Loading sources
... <many lines of per-source "Finished, wrote N rows" / "Skipped" output> ...
  zero_cogs_skus ℹ Skipped
-----
[INFO]:    Evaluated sources, saving manifest
[INFO]:    Done!
<hang here for 17+ minutes before we killed the process>

Process state during hang (Linux, inside Docker container):
  USER       PID  %CPU  %MEM   STAT   TIME    COMMAND
  nextjs    6081   0.9   0.1   Sl     0:09    node node_modules/.bin/evidence sources \
                                              --sources analytics --queries <17 names>

No active queries in the upstream PostgreSQL during the hang
(verified via pg_stat_activity).

System Info

System:
  OS: Linux 6.12 (Unraid OS 7.2.3)
  CPU: (40) x64 Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
  Memory: ~252 GB total
  Shell: bash 5.3.3
  Container: yes (running in Docker)
Binaries:
  Node: 22.18.0
  npm: 10.9.3
Browsers:
  n/a (headless container)
npmPackages:
  "@evidence-dev/evidence": "^40.1.8"
  "@evidence-dev/core-components": "^5.4.2"
  "@evidence-dev/csv": "^1.0.16"
  "@evidence-dev/postgres": "^1.0.10"
  duckdb: transitive via @evidence-dev/evidence (we have not pinned directly)

Severity

annoyance

Additional Information, or Workarounds

What we've tried that does NOT eliminate the hang:

• Running batches sequentially (max 1 parallel subprocess) — still hangs
  in the single subprocess's post-query phase

What we suspect might work but can't easily try:

• Setting threads = 1 on the DuckDB instance inside Evidence

Adjacent context:

• Our Evidence version pin (^40.1.8) was last updated about 8 days ago.
  If a more recent Evidence release addresses this, please point us at
  the changelog entry and we'll bump.
• We have not yet checked Evidence's node_modules internals to see how
  DuckDB is instantiated. If a config-passthrough already exists at the
  code level but isn't documented, we'd take that as an answer too.