Add drive9 — persistent filesystem layer for Daytona sandboxes

[qiffang]

What is drive9?

drive9 is a persistent filesystem that lets data survive sandbox destruction. When mounted inside a Daytona sandbox, it provides:

• Data persistence — code, git history, and files survive sandbox death
• Cross-sandbox sharing — multiple sandboxes mount the same workspace
• Instant forks — drive9 ctx fork creates isolated copies in <1s for safe experimentation
• Standard filesystem — git, node, grep, and all POSIX tools work natively

Why whitelist?

We built drive9-for-daytona, an open-source integration demo showing how drive9 adds a persistent data layer to Daytona sandboxes. The demo creates 3 sandboxes sequentially — each one picks up exactly where the last one left off, because the code lives on drive9, not on sandbox local disk.

The sandbox needs to reach `api.drive9.ai` at runtime for:

• drive9 mount — mounts the persistent filesystem via FUSE
• drive9 ctx fork — creates instant copy-on-write forks
• drive9 fs — file operations (ls, stat, mkdir)

Currently blocked on Tier 1/2 with Connection reset by peer during TLS handshake.

Domains requested

drive9.ai
*.drive9.ai

The wildcard covers `api.drive9.ai` (API server) and any future subdomains.

Demo

Here's what the integration looks like — 3 ephemeral sandboxes, code survives every destruction:

Sandbox A (bootstrap)    →  git init, write code, commit            →  destroyed
Sandbox B (continue)     →  git log sees A's commit, add features   →  destroyed
Sandbox C (fork + break) →  fork, rm file on fork, original safe    →  destroyed

All sandboxes dead. Project + git history persist on drive9.

Full demo: drive9-ai/drive9-for-daytona