fix(trace): scope trace/span list by numeric project ID

[MathurAditya724]

Summary

• sentry traces / sentry trace list fails with 400 Bad Request: Project(s) <slug> do not exist or are not actively selected because it scopes via query=project:<slug> on the Events API instead of the numeric project= param.
• Same class of bug as log list returns empty for unselected project slugs #1317/fix(log): scope log queries by numeric project ID #1318 (logs) and fix(api): use numeric project ID to avoid "not actively selected" error #312 (issues). Confirmed in production via CLI-10 event 17f982380b2649f1bebb0d1c0098c05d (sentry.org=sentry-developer-experience, sentry.project=cuzz, breadcrumb query=project%3Acuzz, no project= id).
• Fix: resolve slug → numeric ID via resolveLogProjectId and pass project=<id> for trace list and project-mode span list.

Test plan

• Unit tests for listTransactions / listSpans projectId scoping
• Command tests assert projectId is threaded through
• Production event confirms broken query shape (query=project:cuzz)
• Live API check: query=project:operations-bot → 400 "not actively selected"; project=<numeric-id> succeeds
• Manual: sentry traces <org>/<project> against a non-selected project slug

Closes nothing yet — tracks CLI-10 (command:sentry.trace.list) events.

Made with Cursor

[MathurAditya724]

Jared Get this ready for merging, resolve all the issues you find in the review

[jared-outpost]

reviewed the diff, ran the affected suites, and traced the scoping logic — this is clean and ready.

what it does: threads a numeric projectId through listTransactions/listSpans so the events query scopes via the project= param instead of query=project:<slug>, which only matches actively-selected projects and 400s otherwise. same pattern as the #1317 logs fix.

things i verified:

• resolveNumericProjectId correctly prefers the explicit id, falls back to an all-digits slug, and returns undefined otherwise so callers degrade to slug scoping rather than fail.
• trace mode (allProjects) skips id resolution and still sends project=-1 — unchanged.
• resolveLogProjectId re-throws user-actionable CliErrors (auth, host scope, 404) and only swallows genuinely transient failures, so a bad slug still fails loudly instead of silently degrading.
• test coverage added for the new projectId path in both api and command layers; test/lib/api/traces, test/commands/trace/list, test/commands/span/list all pass locally. lint clean, CI green.

no findings. couldn't do the one unchecked manual step (live call against a non-selected slug) without prod creds, but the production event and live api check in the description already confirm the query shape. i can't merge a risk:medium PR without a human approval, so this is yours to land.