Memory store never mounts in deployment-created sessions — CMA memory cookbook pattern breaks under scheduled deployments

The Managed Agents memory cookbook (`managed_agents/CMA_remember_user_preferences.ipynb`) demonstrates memory stores with directly-created sessions, and that works exactly as documented. The same pattern does **not** hold when the session is created by a **scheduled deployment**: `/mnt/memory` is absent from the container entirely.

This matters for the cookbook specifically because persistent cross-session memory and scheduled unattended runs are a natural pairing — a recurring agent that remembers what it saw last time is the obvious use case, and it's currently the one combination that doesn't work.

## Expected

`shared/managed-agents-memory.md`:
> Each attached store is mounted in the session container at `/mnt/memory//`.

API reference, `CreateDeployment`:
> Optional session config (`resources`, `vault_ids`, etc.) is supported the same way as on CreateSession.

No documentation states any limitation on memory stores with deployments.

## Actual

`/mnt/memory` does not exist. Not an empty mount point — no directory. Other mounts in the same container are fine (`/mnt/skills`, `/mnt/session/*`, `/mnt/attach`, and an rclone mount for `/mnt/session/outputs`), so mounting works generally; only the memory-store mount is missing.

## Reproduction

Constant across all runs: same agent, same environment (`config.type: "cloud"`), same memory store, same resource object:

```json
{"type": "memory_store", "memory_store_id": "memstore_...", "access": "read_write"}
```

Probe:
```bash
for i in $(seq 1 30); do [ -d /mnt/memory ] && break; sleep 3; done
ls -la /mnt/memory/ 2>&1; mount | grep -iE 'memory|rclone'
```

| Session created via | Mount |
|---|---|
| `POST /v1/sessions` | ✅ rclone FUSE, rw |
| `POST /v1/sessions`, no `instructions` on the resource | ✅ |
| `POST /v1/sessions`, with `instructions` | ✅ |
| `POST /v1/sessions`, `access: "read_only"` | ✅ correctly ro |
| `POST /v1/sessions`, **with `initial_events`** | ✅ |
| Scheduled deployment (manual trigger) | ❌ |
| Scheduled deployment (manual trigger) | ❌ |
| Scheduled deployment (cron fire) | ❌ |

**5/5 direct sessions mount. 3/3 deployment-created sessions do not.**

## Hypotheses ruled out by experiment

- **The `instructions` field on the resource** — present on our deployment resources, absent from the first working session. Tested both ways directly: mounts either way.
- **`access` mode** — `read_only` mounts correctly as ro.
- **`initial_events`** — the most promising theory, since deployments always start a session directly in `running` and the docs note that without `initial_events` "the sandbox comes up when the session first needs it". Tested by creating a session with `initial_events` via raw REST (the `ant` CLI has no flag for it): **it mounted normally.** So immediate-start is not the trigger.
- **Provisioning latency** — waits of 90s and 210s both failed.
- **Self-hosted sandboxes** — documented as not supporting memory stores, but this environment is `cloud`.

## Two suggested changes to the notebook

**1. `mount_path` is not evidence of a mount.** The notebook does:

```python
if resource.type == "memory_store":
print(f"Mounted at {resource.mount_path}")
```

`mount_path` is derived server-side from the store's name and is returned identically whether or not the FUSE mount exists — we confirmed it is present in the session record for every failing session, and it appears even when not supplied at creation. As written, the cookbook would print `Mounted at /mnt/memory/shopper-preferences` for a session with no mount at all. A check against the filesystem (or a note that `mount_path` is the *intended* path rather than a confirmation) would be more robust.

**2. A deployment example would have caught this.** Every memory example uses a directly-created session, so this combination appears untested.

## Impact

The filesystem mount is documented as the interface for memory stores. A scheduled deployment is the primary way to run an agent unattended. Right now those two can't be combined as documented, and there's no way to detect it from the API response — a client checking `mount_path` gets a success-looking value either way.

## Workaround

The `memory_list` / `memory_read` / `memory_write` / `memory_edit` tools are present in the container and do work, so an agent can hydrate state from the store into the workspace and write back at the end. Viable for a once-daily run; expensive at higher frequency. (Noting that `shared/managed-agents-memory.md` says "there are no dedicated memory tools", which appears to be out of date.)

## Environment

- Beta: `managed-agents-2026-04-01`
- Environment: `config.type: "cloud"`, `networking.type: "limited"`
- CLI: `ant` v1.16.0 for deployment creation; raw REST for the `initial_events` test
- First observed 2026-08-13, reproduced 8 times, deterministic

Happy to supply session IDs / deployment IDs privately if that helps trace it.