fix(cli): render the literal [suffix] in --tag help and rejection message

[jawwad-ali]

Problem

Both places a user learns the specify self upgrade --tag syntax silently drop the [suffix] token, because Rich parses the literal square brackets as a markup tag and discards them.

1. The rejection message (_INVALID_TAG_MESSAGE, printed via console.print(str(exc))):

$ specify self upgrade --tag latest
Invalid --tag: expected vMAJOR.MINOR.PATCH          <- [suffix] gone

The constant itself is intact — 'Invalid --tag: expected vMAJOR.MINOR.PATCH[suffix]' — so Rich is the culprit.

2. The --tag option help (Typer renders help through the same Rich pipeline):

$ specify self upgrade --help
--tag  TEXT  Pin the target version (vX.Y.Z). Without --tag, ...   <- [suffix] gone

So the CLI implies a bare vX.Y.Z is the only accepted form, when v1.0.0-rc1, v0.8.0.dev0 and v0.8.0+build.42 are all valid — and the shipped docs advertise the suffix in four places (docs/upgrade.md ×3, README.md ×2). The CLI contradicts its own documentation.

Fix

• Rejection message: escape at the print site, not in the constant. _INVALID_TAG_MESSAGE is also raised through typer.BadParameter (three call sites), which Click renders without Rich — baking \[ into the constant would leak a stray backslash there. So _INVALID_TAG_MESSAGE stays byte-identical and the existing assertion on it keeps passing.
• Option help: escape the literal bracket (vX.Y.Z\[suffix]), since Typer renders it through Rich.

Same literal-bracket class as the existing precedents in workflows/_commands.py (\[disabled], \[<type>]).

After:

Invalid --tag: expected vMAJOR.MINOR.PATCH[suffix]
--tag  TEXT  Pin the target version (vX.Y.Z[suffix]). Without ...

Verification

• test_rejection_message_keeps_the_suffix_token and test_tag_option_help_keeps_the_suffix_token: both fail before, pass after.
• tests/test_self_upgrade_verification.py: 42 passed (40 pre-existing untouched, including test_invalid_tags_rejected).
• uvx ruff@0.15.0 check src tests clean.

Static CLI text only — no validation semantics change, _validate_tag untouched, valid tags behave identically.

---

AI-assisted: authored with Claude Code. I confirmed the constant was intact and Rich was eating the token (rather than assuming a typo), and checked why escaping belongs at the print site instead of in the shared constant.