Define storage isolation for custom ACP server data directories

**Describe the bug**

`AcpServerFactoryConfig` accepts a custom `data_dir`, and the server uses it for session and scheduler state. Some scheduler paths still use process-global data locations, so two co-resident servers with distinct configured directories can read or overwrite state outside their injected roots.

Before changing these paths, the public contract needs to be explicit: is `data_dir` a supported isolation boundary between server instances, or only a storage-location and testing option?

---

**To Reproduce**

1. Construct two `AcpServer` instances in one process with distinct `data_dir` values.
2. Enable scheduling on both servers.
3. Create the same schedule ID with different recipes through each server.
4. Observe that scheduler bookkeeping is separate while recipe storage can resolve through a process-global directory.
5. Run scheduled work and inspect where its session state is persisted.

---

**Expected behavior**

Choose and document one contract:

- If `data_dir` is an isolation boundary, every schedule recipe, session, transcript, and scheduler artifact created by that server must remain beneath the injected root.
- If it is not an isolation boundary, document that co-resident instances share process-global state and make the API intent clear enough that embedders do not rely on unsupported isolation.

---

**Please provide the following information**

- **OS & Arch:** All supported server platforms
- **Interface:** ACP / embedded `AcpServer`
- **Version:** Current `main`
- **Extensions enabled:** None required
- **Provider & Model:** Any

---

**Additional context**

If isolation is supported, acceptance criteria should cover two servers using identical schedule IDs, recipe creation and execution, scheduled-session persistence, restart behavior, and every process-global path reachable from the scheduler. If isolation is not supported, tests should establish the intended shared-state model.

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).