feat(go-server): add DuckDB security profiles

[derekperkins]

Summary

• add compat, catalog-only, and local-files security profiles to the Go server binary
• apply extension, secret, cache, path, external-access, spill, and configuration-lock settings before the query layer starts
• reject remote primary-database paths and canonicalize explicit local file capabilities
• regression-test common DuckDB 1.5.5 URI schemes, replacement scans, writes, attachments, symlinks, and concurrent connections
• document each bundle's guarantees and limitations

Profile contracts

• compat is the default and preserves existing DuckDB and --load-extensions behavior.
• catalog-only disables external access outside DuckDB's primary-database internals, disables spill files and dynamic extension behavior, and locks the configuration.
• local-files adds repeatable --allowed-directory and --allowed-path capabilities to catalog-only. Directory and exact-path grants are read/write capabilities, including COPY and ATTACH.

The strict profiles reject --load-extensions, URI and network-share database paths, and operator-supplied DSN values for profile-owned settings. They remain CLI-local rather than introducing a public cross-package profile API.

DuckDB automatically retains access to its file-backed primary database and related WAL, checkpoint, and recovery paths. Stable symlink escapes are denied, but mutable filesystem state still requires OS or container isolation. Statically linked and core extensions remain available.

The URI regression matrix covers the source-derived http, https, s3, s3a, s3n, gcs, gs, r2, hf, azure, az, and abfss prefixes from the DuckDB 1.5.5 extension-prefix table. This is version-specific best-effort coverage; the native enable_external_access setting is the enforcement boundary.

Commit structure

1. feat(go-server): add DuckDB security profiles
2. test(go-server): cover DuckDB security profiles
3. docs(go-server): document security profiles
4. fix(go-server): scope profile initialization per connector
5. docs(go-server): clarify hardening profile tradeoffs
6. fix(go-server): compose hardening with allowlist defaults

The former standalone startup-exit fix is now inherited from #1150 after the restack, so it was dropped rather than duplicated.

Validation

• go test -count=1 -tags=duckdb_arrow ./...
• go test -race -count=1 -tags=duckdb_arrow ./...
• go test -count=20 -tags=duckdb_arrow . -run '^(TestCatalogOnlyProfileInitializesDistinctConnectors|TestSecurityProfileInitializerIsConcurrent|TestLocalFilesProfileInitializesConcurrentConnections)$'
• go build -tags=duckdb_arrow ./...
• go vet -tags=duckdb_arrow ./...
• golangci-lint run
• git diff --check origin/codex/function-allowlist...HEAD

Stack

This PR is intentionally separate from and based on #1150, which adds the function allowlist. The database profiles provide the resource boundary that a syntactic function policy cannot infer from string arguments.

[derekperkins]

Reviewed the three commits against codex/function-allowlist, so #1150's contents are out of scope here.

This is in good shape. I spent most of the review trying to get out of catalog-only and local-files and could not:

• glob, read_text, read_blob, read_csv outside the grant — blocked, including glob('/*') and <allowed>/../<other>/secret.txt traversal.
• SET, SET SESSION, SET GLOBAL, RESET, and PRAGMA forms of every profile-owned setting — all rejected by lock_configuration.
• LOAD, INSTALL, FORCE INSTALL — blocked, including LOAD of an extension file planted inside an allowed directory, which was the escalation path I most expected to work.
• File-backed primary — the automatic grant is the database file and its .wal only; neighbours, directory globs, ATTACH, and COPY into that directory are all blocked.
• temp_directory='' genuinely prevents spilling rather than silently falling back to a default.

Verified locally on 316ae55 (Go 1.26.5, darwin/arm64, DuckDB 1.5.5): go build, go test -count=1, go test -race -count=1, go vet (all -tags=duckdb_arrow) and golangci-lint run are clean.

Four comments: one code issue that is latent today but silent and total if it is ever hit, the startup exit code, and two documentation points — one of which is asking you to claim a stronger guarantee than the text currently does.

— Claude Opus 5