init: finish source map setup before exposing it as a feature

まず、issue に記載されている現在の init 機能の処理を確認し、その後、実装作業を提案する前に blocker #1110 と PR #1112 を読んでください。受け入れ基準を Definition of Done として扱ってください。source maps を時期尚早に告知してはならず、secrets は init とコミット済みファイルの外部に保持し、production-build の upload 検証は明示的に行う必要があります。

Problem

sourceMaps is currently advertised by sentry init in its --features
help and documentation, while the init service deliberately removes it from
both interactive and CLI-preselected features.

Keeping it disabled is currently the correct behavior. A valid source map setup
requires more than changing bundler configuration:

• Production builds must emit source maps.
• A Sentry bundler plugin or sentry sourcemap inject + upload must run in the
  build that is actually deployed.
• Upload requires a CI-safe Organization Auth Token with the org:ci scope.
• The token must be installed as SENTRY_AUTH_TOKEN in CI and must never pass
  through the init server, LLM context, telemetry, or committed files.
• Browser source maps should normally be hidden and deleted after upload.

Without that flow, init can produce configuration that looks complete while no
artifacts are ever uploaded.

Source maps are also a build/deployment concern, not a runtime product feature
like tracing, replay, or profiling. They should not appear as a peer option in
the feature picker.

Existing blocker

Token management is already tracked by #1110 and PR #1112.

The current organization-token management endpoints only accept browser session
authentication and explicitly reject Bearer authentication. The CLI therefore
cannot mint an Organization Auth Token using its stored OAuth token. This needs
a supported backend flow before it can be automated safely.

This issue should depend on #1110 rather than implementing another token
creation workaround.

Proposed UX

Until end-to-end setup is possible:

• Keep source maps out of the interactive feature list.
• Stop advertising sourcemaps as a currently supported --features value.
• The internal feature/schema value may remain for future planner work.

Once token provisioning is supported, offer source maps as an eligible
build-setup step for JavaScript projects rather than as a runtime feature.

Required setup flow

1. Detect the framework, bundler, production output directory, and CI/build
   configuration.
2. Prefer the official framework or bundler plugin.
3. Fall back to sentry sourcemap inject followed by
   sentry sourcemap upload for custom builds.
4. Configure SENTRY_ORG and SENTRY_PROJECT, while referencing
   SENTRY_AUTH_TOKEN only through the environment.
5. Create an Organization Auth Token with org:ci through the future supported
   token flow, or give the user a secure browser handoff.
6. Explain how to add the one-time token to the project's CI secret store.
7. Use hidden source maps and delete browser maps after upload where supported.
8. Verify using a production build and confirm that an artifact bundle reached
   Sentry.
9. Do not require or invent a release. Modern Debug ID matching works without a
   release; preserve existing release configuration when one already exists.

Acceptance criteria

• Source maps are not shown as supported before the complete flow exists.
• No token value is sent to the init API, an LLM, or telemetry.
• No token or usable placeholder secret is committed to the repository.
• Configuration is correct for the detected bundler/framework.
• Browser builds use hidden maps and avoid deploying .map files publicly.
• CI-secret setup is explicit and actionable.
• A production-build verification checks the actual upload.
• Init does not report source maps as complete when token/CI setup remains.
• Release configuration remains optional with Debug IDs.

References

• #1110
• #1112
• https://docs.sentry.io/account/auth-tokens/
• https://docs.sentry.io/api/permissions/
• https://docs.sentry.io/platforms/javascript/sourcemaps/uploading/