Skip org/project discovery when DSN is already available

[BYK]

When the CLI is used via an AI agent (e.g. MCP/skill), it redundantly attempts to discover org and project names even though DSN scanning already resolves them. This causes unnecessary API calls and, in past versions, excessive re-authentication on nearly every command.

Known symptoms:

• Agent tries to resolve org/project identity on each invocation despite a DSN already being present
• Prior to v0.37.0, this (likely the same root cause) triggered a login call on ~5–6% of commands (~1 in 17); v0.37.0+ dropped to ~0.7% (~1 in 140), suggesting the login over-triggering was fixed but the discovery overhead may remain

Expected behavior:

• When a DSN is available, skip org/project discovery — the DSN already encodes the necessary identity
• Auth should not be re-triggered for operations where an existing token is sufficient

Related: Login over-triggering appears resolved as of v0.37.0; org/project discovery redundancy is still observable in current versions.

[sentry-pierre]

Hi, I'm Pierre!

Merci for the detailed report. I traced the redundant discovery to the resolution layer.

What I checked:

• src/lib/resolve-target.ts::resolveFromDsn calls getProject(orgId, dsnProjectId) on cache miss even though the DSN already encodes the identity.
• src/lib/dsn/resolver.ts::fetchProjectInfo fans out to listOrganizations() and listProjects(org.slug) when resolving numeric DSN IDs.
• resolveOrgAndProject always attempts slug resolution instead of short-circuiting when a DSN is present.

The v0.37.0 login-fix likely helped, but the discovery overhead in these paths remains.