docs: define BTrace 3.0 prepared-mode policy

[jbachorik]

Summary

• record the BTrace 3.0 prepared-mode security and client compatibility decisions
• add deterministic release gates and fail-closed fallbacks to the 3.0 release plan
• update user-facing startup examples to use noServer=true until authenticated prepared mode is available

Why

Issue #872 gates the remaining 3.0 code-readiness work, but the repository did not contain a canonical decision for telemetry consent, prepared-mode binding and authentication, legacy-client behavior, remote control, or Maven fat-agent release eligibility. Without that policy, later implementations could preserve compatibility by silently weakening the security boundary.

The accepted policy makes telemetry opt-in, requires authentication and loopback binding for prepared mode, defers remote control, rejects legacy clients that cannot authenticate, and automatically withdraws Maven fat-agent support if its end-to-end gates fail.

User impact

Launch-time documentation now distinguishes startup-script mode from prepared mode. Startup-script examples that need no later client connection explicitly disable the command server, avoiding accidental exposure of the current unauthenticated endpoint.

Validation

• GRADLE_USER_HOME=$(pwd)/.gradle-user ./gradlew spotlessCheck
• git diff --check
• adversarial acceptance review covering downgrade behavior, unsafe examples, release-waiver ambiguity, and fail-closed fallback behavior

Closes #872

---

This change is