test(sentry): release smoke checklist and scripted API tripwire

[gmaclennan]

Part of #69 (the final acceptance item — running the checklist and signing off at one release — is a process step and stays open on the issue).

Adds the pre-release Sentry smoke checklist (docs/sentry-release-smoke.md), the scripted API tripwire (scripts/sentry-tripwire.mjs), and a manual-dispatch workflow that runs the tripwire from CI. The checklist is linked from CONTRIBUTING.md's release steps and the workflow table in docs/TESTING.md.

The checklist was cross-checked against what the code emits today rather than copied from the issue, which had drifted in three places. The Node-side boot phases (boot.loader-init, boot.manager-init) are not child spans of the comapeo.boot transaction — they arrive as their own transactions on the same trace, since they are root spans in the Node SDK. Per-RPC rpc.client/rpc.server traces only exist under the debug toggle, so the setup section requires debugDefault: true. And captureApplicationData is actually the applicationUsageData toggle (plugin key applicationUsageDataDefault).

For trace discovery the tripwire does not need an injected trace id: there is no debug hook to force one today (the native SDK generates it at each launch), and adding one would touch both native bridges. Instead the script polls for the newest comapeo.boot transaction matching a distinctive sentry.environment value, which the config plugin already propagates to the RN, native, and Node SDKs — so one plugin option uniquely marks a test build with no code changes. --trace <id> is still supported when a specific trace id is known. Discovery uses the org-level Discover events endpoint (the per-project events list from the issue sketch only returns error events, not transactions), then fetches each event's raw JSON and asserts: boot transaction present with op: comapeo.boot, expected native child spans per platform, Node-side boot.loader-init/boot.manager-init on the same trace (cross-process stitching), contexts.device.family == "Android" on the FGS transaction, proc/layer/comapeo.rn tags, environment/release match, and no rootkey/coordinate PII markers. The assertion core is a pure function over fetched JSON (scripts/lib/sentry-tripwire-core.mjs) with a node --test suite, wired into lint.yml via a new test:scripts script.

The workflow (sentry-tripwire.yml) deliberately does not build or launch an app: you launch a test-DSN build yourself (local device or BrowserStack session per the checklist) and then dispatch the workflow with the same environment or trace id. Building and driving an emulator in CI felt disproportionate for a manual pre-release check and would make the run flaky on ingestion latency; the script itself is dependency-free, so the job is checkout + setup-node + run. It needs a SENTRY_TRIPWIRE_TOKEN secret (read access to the test project's events).