docs: external-party outbound transfer (registry config + runbook + API)

## Background

The outbound-to-external-party path has operational nuances (2-phase offer/accept, expiry, registry dependency, claim-back) that need to be written down for integrators and operators.

## Scope

- **API docs** for the new endpoints (`/api/v2/transfer/external/prepare|execute`, custodial `/api/v1/transfer/external`), including the 2-phase semantics: success = offer submitted, not settled.
- **Config docs**: `token.external_tokens` (InstrumentAdmin → RegistryURL) must include the recipient token's registrar for outbound; note that registry reachability is a **hard dependency** of `prepare` (registry down → prepare fails).
- **Operator runbook**: what happens when the recipient never accepts (offer expires, holdings unlock) and how the sender reclaims via the claim-back flow (#292).
- Follow the existing `docs/*-design.md` pattern.

## Acceptance

- `docs/` page covering the outbound external-party transfer path end-to-end.
- Config reference updated with the external-token registry requirement for outbound.

Start with the existing docs/*-design.md pattern and inspect the docs/ pages covering transfers and configuration. Document the prepare/execute and custodial endpoints, the token.external_tokens registry requirement, registry reachability, expiry and unlock behavior, and the claim-back flow in #292. Done means one end-to-end outbound external-party transfer page and the config reference update described in the acceptance criteria.

Written by the indexing model from the issue text.