Add an in-process Sentry sink transport (daemon-free logging for backend/CLI/test)

[DawidWraga]

Context

The logs-server daemon isn't actually required for single-process logging. A custom Sentry transport can serializeEnvelope() (from @sentry/core) → handleIngest(openDb(dbPath), text) and write straight into the sink SQLite — no HTTP, no daemon, no second process. Proven in titanium-admin/bun-kysely-test (the compiled binary's embedded mode) using the new @davstack/logs-server@2.10.0 /sink export.

Proposal

Ship an official transport helper, e.g. @davstack/logs-server/transport exporting:

davstackSinkTransport({ dbPath }): (opts: BaseTransportOptions) => Transport

for @sentry/node / @sentry/bun. One line in Sentry.init({ transport }) gives a project daemon-free backend/CLI/worker/test logging into the same davstack-schema SQLite, queryable with the usual sqlite3 … ->> recipes — no "start the daemon" step, no port, no per-project wiring.

Caveats to design around

1. Browser can't use it — no filesystem; browser telemetry still needs the HTTP daemon. This helper is for backend/CLI/worker/test processes only.
2. Current /sink is bun-only (openDb imports bun:sqlite). Node projects (e.g. titanium Next.js) need a node:sqlite (Node 22+) or better-sqlite3 backend behind the same openDb/handleIngest seam. This is the main chunk of work.
3. Multi-writer concurrency — several in-process writers to one file vs the daemon's single writer. WAL + busy_timeout handles it, but cross-service trace aggregation only holds if they share the same file path.

Reference

titanium-admin/bun-kysely-test/src/lib/logger.ts — embeddedSinkTransport(dbPath) (the ~15-line transport) plus the 3-mode initObservability (local daemon / embedded / cloud). A 14-day retention prune runs on boot there since the daemon's autoclean doesn't run in-process — the helper may want an opt-in equivalent.