Persist local /etc/claude-sandbox.conf edits across rebuilds and updates

Title: Persist local /etc/claude-sandbox.conf edits across rebuilds and updates

## Problem

Since the disposable-clone install (#4), the documented way to customise the sandbox conf (`allow-write`, `allow-ip`, `pass-env`, …) is editing `/etc/claude-sandbox.conf` directly in the container (#5). Those edits are per-devcontainer and ephemeral:

- a **container rebuild** recreates `/etc` from the image;
- a **re-install / `claude-sandbox update`** re-stamps `/etc/claude-sandbox.conf` with the shipped defaults from the fresh clone (`install_conf`), silently clobbering local lines.

The re-stamp is deliberate for the dogfood and pinned-team-clone flows (the clone conf is the source of truth and upstream conf improvements must propagate), so seed-only-if-absent is not an option.

## Proposed direction: a local overlay the installer never touches

Keep `install_conf` stamping the shipped defaults, and have the shadow additionally read a local overlay — e.g. `/etc/claude-sandbox.local.conf` (or `/etc/claude-sandbox.conf.d/*.conf`) — after the base conf:

- local edits go in the overlay and survive every re-install/`update`;
- Invariant 4 holds: still root-owned, under `/etc`, outside the jail's rw set;
- rebuild persistence could then be a documented one-liner (e.g. copy the overlay into a pinned team clone, or a postCreate that restores it) — or a later mount-based mechanism.

Touches `claude-shadow`'s `parse_config` call site, `install.sh` docs, `tests/bwrap_argv.sh` + `tests/smoke.sh`, and the conf docs updated in #5.

Related: gilesknap/claude-sandbox#81 (per-project `.claude-sandbox.conf` via the container launcher's gated read) — different mechanism, same "custom conf without a persistent clone" itch; whichever lands first should reference the other.

Start at claude-shadow’s parse_config call site and read install.sh alongside the conf documentation from #5. Run tests/bwrap_argv.sh and tests/smoke.sh to understand current parsing and installation behavior. Done means local overlay settings survive reinstall/update, remain outside the jail’s writable set, and are covered by updated tests and documentation.

Written by the indexing model from the issue text.