Define servicing-branch policy for external test assets

## Problem

External integration-test binaries have historically been retained so servicing branches can continue using their original payloads without being updated whenever platform requirements change. This has resulted in old and duplicate blobs remaining indefinitely, with no documented rule for when they may be replaced or removed.

Blob cleanup cannot be performed safely until supported servicing branches and their asset dependencies are known.

## Proposed work

- Identify the XHarness servicing branches that remain supported.
- Map each supported branch to the external Android, Apple, and WASM payloads it references.
- Retire obsolete servicing branches according to the repository's support policy.
- Define whether payload paths are immutable or versioned for branches that remain supported.
- Document when an old blob may be replaced, archived, or deleted.
- Ensure future payload updates use paths that do not silently change servicing-branch inputs.

## Completion criteria

- Supported servicing branches and their external asset dependencies are documented.
- A clear retention and naming policy exists for external test payloads.
- Obsolete assets can be identified without risking supported branches.

_This issue was created with AI assistance._

Start by identifying the XHarness servicing branches that remain supported and mapping each one to its external Android, Apple, and WASM payloads. Check the repository's support policy before deciding which branches and assets are obsolete. Done means the supported dependencies, retention and naming rules, and safe replacement, archival, or deletion criteria are documented.

Written by the indexing model from the issue text.