Report org and app IDs on command stats from token scope

[clouvet]

Follow-up to #5130, which added app_id/org_id to the command/stats payload but never populated them.

Approach: derive the IDs from token scope, not from an app lookup

Our tokens are already scoped to an org, and sometimes to an app. flyio.OrganizationScope/flyio.AppScope read that straight out of the macaroon caveats, so this costs no API call and works for commands that never fetch an app. Measured at ~5.8µs per invocation.

The alternative — calling GetApp during command setup — looks appealing but inverts the value:

	app-scoped command packages
Total (RequireAppName/LoadAppNameIfPresent*)	128 files / 39 packages
Ever call GetApp	5 (apps, deploy, mcp, registry, secrets)

Those 5 overlap heavily with deploy/launch, which already report both IDs on their own payloads. The other 34 — status, logs, ssh, scale, machine, volumes, ips, certificates, config, console, … — only ever deal in an app name, and command/stats is the only event covering them. So a GetApp-based approach would mostly duplicate IDs we already have, add a network round trip to every invocation of the highest-volume event we emit, and introduce a network failure mode into RequireAppName, which today does no I/O at all.

Expected coverage

org_id is reported when every permission macaroon agrees on one org:

• CI and deploy tokens (single org-scoped macaroon) — reported
• Users belonging to one org — reported
• Users in several orgs — not reported. fetchOrgTokens deliberately holds one macaroon per org, so there is no correct single answer without knowing the app; we emit nothing rather than guess and mis-attribute.
• OAuth-only tokens — not reported; OAuth tokens are per-user and carry no org.

app_id is only reported by tokens narrowed to exactly one app (fly tokens create deploy -a …), so expect it to be empty far more often than org_id. AppScope already returns nil for a wildcard token, so a non-empty result always names specific apps.

Both fields are omitempty, so an invocation we can't attribute sends exactly what it sends today.

Also: removes the context helpers from #5130

WithAppID/WithOrgID/AppIDFromContext/OrgIDFromContext could never have worked. RecordCommandFinish reads the package-global commandContext, which startMetrics snapshots once — 11th of 12 in commonPreparers, before auth and before any command-specific preparer runs. Contexts are immutable, so ctx = metrics.WithAppID(ctx, …) later produces a different context the global never sees. Replaced with a mutex-guarded package-level setter, matching how metrics.IsUsingGPU is already reported from command.go.

⚠️ Companion change still required

flyctl-metrics PR #70 accepts these fields on command/stats but deliberately does not forward that endpoint to Rudderstack, because the IDs weren't populated yet. Landing this without restoring the go sendToRudderstack("flyctl_command_stats", …) block in flyctl-metrics main.go (it's in commit c500ecc) means the IDs still never reach Snowflake. I have not touched that repo.

Test plan

• go build ./...
• go vet ./...
• go test ./internal/config/... ./internal/command/
• New TestScopedIDs covering single-org, multi-org, OAuth-only, nil, single-app and multi-app tokens
• Verified end-to-end against a real FlyV1 fm2_… token: org ID extracted, zero network calls