fix!: rework plugin configuration block - #33

- one hung remote sandbox like Daytona or Vercel request can prevent the server process from exiting indefinitely.
- shutdown interrupts every active session and awaits settlement.
- mount finalizers release their sandbox leases.
- `Sandbox.stop` rechecks the current refCount while holding the sandbox lifecycle gate.
- If refCount > 0, it returns SandboxBusyError; shutdown logs that failure and continues.

- add location-level errors for missing paths and paths that are not directories,
 and expose them through the session.create and session.relink RPC contracts.
- preserve Runner.SandboxDirectoryNotFoundError for persisted session directories that disappear during execution.
- mark sandbox filesystem adapter layers as fresh so long-running servers do not reuse a memory or SQLite filesystem for later local mounts.
- add RPC coverage for relative sandbox paths, invalid local paths, relinking, and filesystem isolation across sandbox mounts.

A `plugins` entry is now either a module or a configuration object. A module is a
definition, a path, a `file:` URL, or a package spec; it loads and takes the position
it is written at. A configuration object names a plugin something else selected, by ID
(`plugin`) or by the package it came from (`package`), and never loads, installs or
reorders anything — a name matching nothing in the selection is ignored.

- Replace the `"!id"` disable syntax with `{ "plugin": "...", "enabled": false }`.
- Deliver a per-plugin `options` block as `setup(ctx, options)`. The block is opaque:
  it replaces rather than merges, and survives settings normalization and the layer
  merge so a `null` inside it reaches the plugin.
- Alias a loaded module by its package name, spec, path and manifest name, so a
  configuration entry can address it without knowing the plugin ID.
- Treat a plugin ID as a key: the last module to claim it owns it, and configuration
  written against it stays with the key.
- Fail on corrupt configuration instead of absorbing it. A settings file that exists
  and cannot be read, parsed or decoded fails the load with its path, reason and
  offending key, at construction and at the capture after an edit breaks it.
- Carry `SettingsError` through the run error channel as the `settings` failure
  category, and give it and `SnapshotError` a `message`, which clients received empty.
- Validate entry shape in `prepare` for callers that never pass through decoding.
- Add worked examples under `extras/`: `@acme/codework-tool-proc`,
  `codework-prompt-life`, and two single-file plugins, loaded for real by the tests.

BREAKING CHANGE: a bare string is a module only, so a built-in is no longer selected
by ID; settings address built-ins through `{ "plugin": "codework.tool.bash", ... }`,
and an embedder composing its own order passes its whole selection. `Plugin.setup`
takes a second argument. A malformed settings file now fails instead of warning.