fix: stream and async R2 database dumps

[akamabu]

/claim #59

Summary

Fixes #59 by moving database dumps away from building the entire dump in memory and adding an R2-backed asynchronous export path for large databases.

What changed

• /export/dump now returns a ReadableStream instead of assembling a single giant string/blob in memory.
• Table data is exported in bounded LIMIT/OFFSET pages (EXPORT_CHUNK_SIZE configurable, default 500).
• SQL identifiers and values are safely escaped for generated INSERT statements.
• Added optional async mode: GET /export/dump?async=true
  • Requires EXPORT_BUCKET R2 binding.
  • Writes dump_YYYYMMDD-HHMMSSZ.sql to R2 by default.
  • Supports filename= query parameter.
  • Supports callback notifications via callbackUrl= or EXPORT_CALLBACK_URL.
  • Uses ctx.waitUntil when available so the request can return 202 Accepted while R2 upload continues.
• Added Env/config wiring for EXPORT_BUCKET, EXPORT_CALLBACK_URL, and EXPORT_CHUNK_SIZE.
• Expanded dump tests for streaming, pagination, escaping, async R2 upload, custom filename, and callback behavior.

Testing

• npx vitest run src/export/dump.test.ts ✅
• npx vitest run was also run; the new dump tests pass, while 4 pre-existing unrelated RLS tests fail in src/rls/index.test.ts.

[digzrow-coder]

The async path still cannot satisfy the "continue past the 30s window" part of #59. It returns 202, but the export work is still a single bucket.put(filename, createDatabaseDumpStream(...)) promise kept alive with executionContext.waitUntil(job). Cloudflare documents waitUntil() as sharing a 30-second post-response limit for a request, so any export that needs longer than that can be cancelled before R2 upload/callback completion: https://developers.cloudflare.com/workers/runtime-apis/context/#waituntil

There is also no persisted checkpoint/job record, so if that background promise is cancelled there is nowhere for a later request/alarm to resume from. For the large 10GB case in the issue, this can return { status: "accepted" } and then silently fail or leave an incomplete object instead of delivering a completed dump.

The async path needs to move the continuation into a resumable mechanism (DO alarm/queue/workflow plus persisted table/offset/R2 state), or otherwise keep the response open as a true pull-driven stream. waitUntil(bucket.put(...)) alone only hides the timeout from the caller; it does not make the export durable.