Support show_default string in prompts

[MirrorDNA-Reflection-Protocol]

Summary

Fixes #2836

When show_default is set to a string on an Option with prompt=True, the string was only used in the help text but not in the actual prompt. Now the custom string is also displayed in the prompt, matching the behavior of help text.

Before

@click.option('--name', default='default', show_default='show_default', prompt=True)

Help: --name TEXT [default: (show_default)] ✓
Prompt: Name [default]: ✗ (shows actual default, not custom string)

After

Help: --name TEXT [default: (show_default)] ✓
Prompt: Name [(show_default)]: ✓ (now shows custom string)

Changes

1. _build_prompt(): Updated to accept str | bool for show_default. When it's a string, display it in parentheses (matching the help text format).

2. prompt(): Updated signature to accept str | bool for show_default parameter, and updated docstring.

3. Option.prompt_for_value(): Now passes show_default to prompt() regardless of type (previously only passed it when it was a bool).

Testing

Manually tested with the reproduction case from the issue. The prompt now correctly shows the custom show_default string.

[kdeldycke]

This looks like a copy of #2837 which has been closed by the original author. I guess I can rebase it on top of stable for a future release.

#3262 on the other hand is a copy of that one.

[kdeldycke]

Just added some tests on top of the original PR, including edge-cases and UNSET sentinel. Refactored the code a bit to streamline the code and reduce diff.

This PR is ready to be merged upstream on top of stable for the upcoming 8.3.3 release.

[davidism]

AI generated

[kdeldycke]

@davidism : this PR may have been initially AI generated, but still fix a legitimate issue. That's why I took over it 2 weeks ago to amend and fix its slop. See the comment history.

Now that 8.3.2 has been release, I propose to start the 8.3.3 merging phase with this PR first: it is addressing an issue that a lot of AI have tried to solve in the past few weeks. So merging this will cut all the AI generated siblings.

[davidism]

I'm not interested in cleaning up AI generated code. I don't want those contributions. I'm sorry you put time into this, but I'd rather that time be spent on creating a PR by hand rather than laundering an AI contribution

Look at the users contribution graph. It's obvious that they're not putting time into anything they're doing. I'm not interested in encouraging that behavior.

[kdeldycke]

I'm not interested in cleaning up AI generated code. I don't want those contributions. I'm sorry you put time into this, but I'd rather that time be spent on creating a PR by hand rather than laundering an AI contribution

Look at the users contribution graph. It's obvious that they're not putting time into anything they're doing. I'm not interested in encouraging that behavior.

I understand. When I started working on that issue I realized we had a human-contributed solution at #2837. But the initial user deleted his forked repository so I could not rework its contribution within the #2837 PR. So I defaulted to the oldest PR which is this one. I wasn't 100% sure this PR was AI-generated so with the benefits of the doubt, and to not erase the original author commit infos, I decided to build on top of it.

I can recreate a clean PR with my modifications to fix #2836 once and for all.

[davidism]

You can still get the patch for a PR, even if the branch has been deleted by appending .patch to the URL. You can apply that in a new branch to re-create the PR while preserving that users credit.

[kdeldycke]

This PR has been superseded by #3328.