Generate an operation catalog for SDK consumers #109

Part of v1.0.0 #93.

Publish a generated, data-only operation catalog from @sentry/api so consumers can discover the API shipped with their installed SDK without downloading another OpenAPI document or parsing the SDK bundle. Toolkit #1658 is the first consumer: sentry schema needs operation identities and searchable metadata as the API grows.

SDK contract

• Export the catalog and its types through an optional @sentry/api/operations entry, without importing the HTTP client or optional validators.
• Generate canonical HTTP method/path, actual exported function name, original OpenAPI operation ID, summary/description/tags, deprecation, path parameter names, and query parameter metadata including inherited overrides and scalar/array-item enum values.
• Derive identities from the same OpenAPI and generated SDK sources used by the package build. Reject missing or ambiguous mappings; do not infer names from the bundled JavaScript or maintain per-endpoint registrations.
• Verify regeneration with added operations and parameter values, normalized legacy operation IDs, and imports/types from the packed package.

Consumer boundary and v1 fit

This complements #102: the catalog provides runtime discovery metadata, while #102 provides type-only input/response mappings for frontend inference. Keep their canonical method/path identities compatible. Neither requires the routing or retry implementations to ship first.

CLI command paths, aliases, command-to-operation analysis, search ranking and grouping remain in Toolkit. Filters such as dataset=logs, is_transaction:true and type:metric_issue belong to the calling implementation, not the generic API catalog.

Validate Toolkit against the packed SDK change, then adopt the published export after the SDK release. This issue does not change request execution, API publication policy or the existing root exports.