Design: host-enforced agentsh injection via CLI overlay + per-devcontainer network topology

## Summary

Design + track the move from **project-opt-in** notifier enrollment (the `remo-notifier-source` devcontainer Feature added per-project in `devcontainer.json`) to **host-enforced injection** of agentsh + the source connector via the CLI overlay (`--additional-features`), plus the supporting network topology.

Design proposal / target architecture, not a mechanical change. Depends on and interlocks with #41 (deacon migration).

## Background

- Spec 009 made the notifier multi-source: one notifier per host, many devcontainers each with their own agentsh, each enrolled via a held-open presence connection (`POST /v1/sources` → `{source_id, api_url, api_key, labels}`). The open connection *is* the registration and carries the poll-back path (`api_url`).
- Today enrollment is **opt-in**: a project that omits the `remo-notifier-source` Feature is simply never gated. For a security control that's a weakness.
- The current Feature is the **connector only** — it assumes agentsh is already present/running in the container and just registers its URL+key. agentsh itself is not packaged as a Feature in this repo.

## Proposal — host-overlay injection (mandatory, non-opt-in)

Both deacon and the reference devcontainer CLI support `--additional-features` (deacon confirmed: `examples/up/with-features/`; merge = shallow override, **CLI precedence**). The host already invokes the CLI (`project-launch.sh.j2`, `devshell.sh.j2`, `user_setup/tasks/main.yml`), so:

- A host "configured for this capability" passes `--additional-features '{...}'` on every `up`, injecting the connector (and a future agentsh Feature) into **every** container — no per-project `devcontainer.json` edit.
- CLI precedence makes the gate **host-enforced and non-bypassable** per-project.

### Convention-based uniform overlay

If scheme (`http`), agentsh port, API base path, and approver key path are all **convention**, the only per-container variable is the container's network name — which the container knows at runtime. So the overlay is a single uniform blob (notifier coordinates + conventions); the connector self-fills its identity and builds `api_url` from convention. Collapses the per-container config surface to **one self-derived value**.

### Requirements this pushes onto the connector / agentsh Feature
- All per-container inputs must be **runtime-derivable**, not hardcoded per project.
- `sourceId` already defaults to hostname; `api_url` must derive from the container's resolvable network name; `apiKey` from a conventional file path.
- **agentsh must become a devcontainer Feature** (install + launch) — only the connector exists today. (New sub-issue.)
- Verify injected-feature lifecycle/entrypoint behavior under deacon matches declared-in-config behavior.

## Network topology

**Chosen: per-devcontainer network, notifier multi-homed** (east-west isolation):
- Each devcontainer on its own user-defined network → spokes can't reach each other.
- Notifier `docker network connect`'d into each network → reaches all; routes between none.
- `notifierAddress` becomes name-based (`http://notifier:18181`).
- Source/container names must be **globally unique per host** (notifier is multi-homed → ambiguous resolution otherwise). Pin hostname == network alias == sourceId.
- Detach / cleanup on container stop to avoid stale attachments; watch veth/interface count at high source counts.
- Trade-off: notifier present in all networks is a deliberate hub → pivot risk if compromised. Acceptable, but stated.

### Decision — attach mechanism: **Option A (host wires at launch)**

The network attach is a **prerequisite** for registration, so it cannot be triggered by the registration POST. **Decision: the host orchestration layer** (already runs `up`, already has Docker access) performs `docker network connect notifier` at container launch, **before** the connector starts; then the connector reaches the notifier over the freshly-wired path and registers normally.

Rejected alternative (Option B — notifier self-attaches via the Docker socket): requires a pre-existing out-of-band path for the registration POST **and** mounting the Docker socket into the notifier — a root-equivalent privilege grant to the security-gating component (compromise → control of all containers). Not pursued.

Simpler non-isolating alternative (single shared user-defined network) is also rejected: every devcontainer could reach every other (no east-west isolation).

## Open questions
- Exact convention for agentsh port / key path / API base.
- Name-pinning mechanism (`runArgs: --hostname/--network-alias` vs other).
- Migration path for projects already using the opt-in Feature (keep both? deprecate?).
- Static `[agentsh]` seed source (spec 009 FR-005) interaction with overlay injection.
- Where exactly host orchestration creates the per-container network and runs `docker network connect` (which launch script / Ansible task), and the detach-on-stop hook.

## Dependencies / links
- #41 — deacon migration (the overlay seam lives in the same launch scripts).
- New sub-issue (to file): package **agentsh as a devcontainer Feature**.

## Out of scope
- The notifier service core (multi-source registry/poller from spec 009 is unchanged).
- remo CLI command surface (this is host-provisioning + container-launch internal).

Start with project-launch.sh.j2, devshell.sh.j2, user_setup/tasks/main.yml, and deacon’s examples/up/with-features/ to trace the existing launch and overlay paths. The design is done when the conventions, naming, network creation and cleanup points are decided, host attachment precedes connector startup, and injected-feature lifecycle behavior is verified.

Written by the indexing model from the issue text.