fix: Improve metavar display consistency in Rich help output

[by22Jy]

Summary

Fixes #1156

Improves the consistency of metavar display in Rich help output for Arguments with custom metavar.

Problem

When using Rich help output, Arguments with custom metavar show inconsistent behavior:

# Example with custom metavar="user"
@app.command()
def show(user: str = typer.Argument(..., metavar="user")):
    ...

Before (confusing):

Arguments:
  *    user      MY_ARG  [required]
       ^^^^      ^^^^^^^
       looks like param name  but is metavar

The metavar user appears in the parameter name column, making it look like a type annotation.

Solution

Smart detection of custom vs default metavar:

• For Arguments with custom metavar: Use metavar as the parameter name, show the actual type in the type column
• For Arguments without custom metavar: Preserve original behavior unchanged
• Non-breaking: Only affects Arguments with custom metavar

After (correct):

Arguments:
  *    MY_ARG      TEXT  [required]
       ^^^^^^      ^^^^
       metavar as name  type shown correctly

Changes

• Modified typer/rich_utils.py to detect custom metavar for Arguments
• For Arguments with custom metavar: display metavar in name column, type in type column
• Preserves all existing behavior for Options and Arguments without custom metavar

Testing

• ✅ All 210 related tests pass
• ✅ Tested with both required and optional arguments
• ✅ Verified no regression for Options
• ✅ Verified no regression for Arguments without custom metavar

Related

• Closes Argument(metavar="MY_ARG") has different meaning for the arguments panel compared to the usage text or the non-rich help output #1156
• Related to 🐛 Make second column of Rich help output reflect the type consistently, even when using metavar #1410 (addresses same issue with different approach)

Checklist

• Code follows project style guidelines
• All tests pass
• Non-breaking change
• Minimal, focused changes

[svlandeg]

Please clarify how/why this differs from #1410, and include a meaningful unit test to showcase behaviour, thanks!

[svlandeg]

I'm going to close this. Feel free to review #1410 if you think something is wrong with that approach. That PR contains a lot more background information, examples, and unit tests, and was already recorded as a solution to #1156. Reviewing different PRs (especially when they're not complete, i.e. lacking unit tests) for the same issue creates too much maintenance burden.