[tigh-latte]

Usage telemetry stack, part 7 of 8. Builds on #573. Next: #585.

Description

This PR lets each command say what telemetry it may send, in one place, with a decorator:

from .. import telemetry

@main.command()
@telemetry.send(telemetry.ERRORS)
def start(...):
    ...

Policy	Sentry error reports	Usage events
ALL (default)	Yes	Yes
ERRORS	Yes	No
USAGE	No	Yes
NONE	No	No

• Nearest wins. A policy on a group applies to every command under it, unless a command sets its own.
• It only narrows. DO_NOT_TRACK, CLOUDSMITH_NO_TELEMETRY and telemetry = false always win, and every other rule (non-Cloudsmith hosts, SSL off, shell completion, user errors) still applies.
• One reviewed list. test_every_command_that_sends_less_than_all_is_listed_here walks the whole CLI and lists every command that sends less than ALL, so a policy change always shows up in the diff.

This replaces the list of excluded command names in core/usage/run.py, which lived far from the commands and silently stopped matching when a command was renamed. The policy is read from the Click context: by collect_facts for usage events, and by AliasGroup.main before it reports an unexpected exception.

Policies set in this PR (the same behaviour as before):

Command	Policy	Why
credential-helper docker / cargo / generic / pnpm / terraform	ERRORS	Run by package managers on every request; crashes are still worth knowing about
mcp start	ERRORS	Long-running
telemetry group	ERRORS	Manages telemetry itself

Behaviour changes

• CLOUDSMITH_TELEMETRY=log now covers error reports too: the scrubbed Sentry event is printed to stderr instead of being sent, even without a DSN. Before, log mode showed usage events only, and an error report was still sent, although the first-run notice says log mode shows exactly what is sent. The opt-outs still win in log mode.
• CLOUDSMITH_TELEMETRY and log_mode() move to core/telemetry_common.py, shared by Sentry and usage telemetry; core/usage/settings.py re-exports them.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactoring
• Other (please describe)

Additional Notes

cloudsmith_cli/cli/telemetry.py only imports the stdlib-only core/telemetry_common.py, so importing it from command modules adds nothing to startup (test_startup_imports.py still passes). The telemetry command module imports send and ERRORS directly, because it defines the telemetry group itself.

[cloudsmith-iduffy]

Are we duplicating efforts across sentry and posthog if both are taking in errors? Should we be keeping posthog focused on getting data to understand how the cli is being used? or does it taking in errors have value? or should we get rid of sentry and use posthog for everything?