Security model: intended trust boundary for untrusted customer code

Thanks for all the great work on celld! 🙌

## Context

We are evaluating celld as the stateful V8 profile for customer-authored workflow and agent code. We have read the current [security](https://github.com/denoland/celld/blob/main/docs/security.md) and [limitations](https://github.com/denoland/celld/blob/main/docs/limitations.md) pages and understand that today celld is explicitly not safe for hostile multi-tenant use, and that a fleet runs one application.

We are asking about the *future* direction so we build against the right trust boundary rather than guessing.

## What we are comparing against

Cloudflare Durable Objects give us a useful reference for the isolation properties we care about:

- each object has one active single-threaded instance at a time;
- each object has private transactional storage exposed only to that object;
- input gates prevent new events from interleaving with pending storage reads;
- output gates delay external messages until pending storage writes commit;
- objects hibernate and migrate, with durable state surviving the move.

We are not asking celld to reproduce Cloudflare's full edge platform. We want to know which of these properties celld intends to guarantee as its own security model, and at what granularity.

## The question

Which long-term deployment model should we build against?

1. One trusted application per fleet, with the process or fleet as the trust cell.
2. Hostile customer code is supported, but one celld process or fleet is the trust cell (we isolate each organization-level fleet under gVisor or Firecracker and keep network, secrets, and native tools behind external capabilities).
3. Mutually hostile Workers sharing one celld process is an eventual goal.

For model 2, we can already contribute the outer isolation and capability layer ourselves. For model 3, we would want to know whether focused contributions around a sandbox-enabled celld build, sandbox conformance CI, and a rootless container profile would fit the project.

We are not requesting a control plane, scheduler, or account service. We want to avoid building against a security model celld does not intend to support.

## What we can offer

If any of this is in scope, we can contribute focused, tested patches (via the `git format-patch` path) rather than broad proposals. We would start with the smallest useful unit and respect review time.

Start with docs/security.md and docs/limitations.md, then review the trust-boundary options and isolation properties described in this issue. Done means the project has a clear, documented decision about which deployment model celld intends to support and whether sandbox, conformance CI, or rootless-container contributions fit that model.

Written by the indexing model from the issue text.