[Spike] Evaluate one bounded backend on an authorized DemoLab device

[jacklv-coder]

Goal

Produce an evidence-based Go or No-Go decision for one narrowly bounded backend candidate on one explicitly authorized, dedicated test device using only first-party DemoLab.

This issue is not a support claim and does not authorize implementation of a general device service.

Blocked until

• RFC-0001's Go/No-Go checklist is copied into a focused backend ADR/test plan
• versioned capability/error/manifest contracts from Define bounded v0 capability, error, and export schemas #7 are reviewed
• bounded protocol design from Draft RFC-0002 for the bounded host/helper protocol #8 is reviewed
• Research a representative first-party protected DemoLab oracle #9 establishes what claim the first-party fixture and oracle can actually support
• the maintainer privately confirms ownership/authorization and supplies only the sanitized environment tuple below

Sanitized environment tuple

Record publicly only:

• device marketing model and SoC family
• exact iOS version and build
• public jailbreak/test-environment name and version
• rootless or rootful mode
• macOS version and architecture
• exact OrchardProbe and DemoLab commits
• public transport/backend capability IDs
• helper artifact SHA-256, if exercised

Do not post a UDID, ECID, serial number, IP address, hostname/username, port, credential, token, pairing material, proprietary app identity, IPA, binary, receipt, or raw log.

Spike constraints

• choose one candidate and one exact environment; do not infer support from iOS version alone
• first target is DemoLab only
• no modification, re-signing, reinstallation, redistribution, app data access, or unrelated process access
• no shell, arbitrary path, caller-selected PID, task-port brokerage, raw address, arbitrary range, executable upload, LAN listener, or persistent helper
• helper must be short-lived, session-bound, USB-preferred, bounded, fail-closed, and removable
• failures must not broaden privileges or silently switch transport/backend
• an unencrypted DemoLab build can validate plumbing only, never a decryption claim

Required evidence

• two clean runs including helper teardown/restart
• exact capability transcript and numeric bounds, sanitized
• target, bundle, entry, and code-range containment checks
• per-binary outcome/evidence for app, framework, and extension
• negative tests for wrong session/target, malformed/oversized frame, traversal/symlink/special file, short read, disconnect, cancellation, target/mapping replacement, quota, and low disk
• independent known-plaintext oracle where the recorded claim requires it
• no device/proprietary output uploaded to GitHub or CI

Exit

Close with one of:

• Go: one exact candidate/environment is safe enough for a separately reviewed implementation PR; or
• No-Go: record the failed assumptions, residual risk, and next product decision.

A Go decision still does not add a compatibility-matrix row; that requires the separate maintainer verification process in docs/compatibility/.

Related: #6, #7, #8, #9.