`--labels` accepts an invalid `@`-prefixed label instead of stripping or rejecting it

Summary

td task add --labels "@Foo" attaches the label literally as @Foo. Since @ is display syntax and never part of a stored label name, this produces an invalid label: it renders as @@Foo in the UI and never appears in the UI's label-management list. The CLI accepts it silently — no strip, no warning, no error.

Repro (td 5.3.6)

td task add "repro" --labels "@ZZTEST_Mode:Foo" --json
# -> task labels: ["@ZZTEST_Mode:Foo"]

td label list --json
# -> appears under sharedLabels as "@ZZTEST_Mode:Foo"

In the Todoist UI the task shows @@ZZTEST_Mode:Foo, and the label does not appear in the label-management list — confirming it is not a valid label.

Actual

The CLI stores an invalid label name (leading @).

The fix (maintainers' call)

A leading @ in a --labels value is never valid. The CLI should not accept it as-is. Either option resolves it:

• Strip the leading @ so @Foo and Foo resolve to the same label; or
• Reject with a clear error.

We don't have a strong preference — the key point is that silently storing @Foo is wrong.

Note — inconsistency inside the CLI

td label remove-shared "@ZZTEST_Mode:Foo" already strips the @ and looks up ZZTEST_Mode:Foo:

Error: LABEL_NOT_FOUND
Shared label "ZZTEST_Mode:Foo" not found.

So the CLI normalises a leading @ on remove-shared, but not on the --labels apply path.

Bundled skill guidance

The package ships a todoist-cli agent skill (SKILL.md). Until the CLI handles this, the skill should teach agents the rule explicitly: never pass a @ to --labels (or an MCP labels array); the @ belongs only in td task quickadd strings, where the parser strips it. Ideally the skill says to strip a leading @ from any label value before applying.

Environment

• td 5.3.6

Trace the --labels apply path and compare its handling with td label remove-shared, which already strips a leading @; also inspect the bundled todoist-cli SKILL.md guidance and the quickadd/MCP label references. Reproduce with the commands in the issue, then ensure the chosen strip-or-reject behavior prevents @-prefixed labels from being stored and is reflected in the skill guidance.