Accept password values that start with a dash (#1752)

[barry3406]

Description

mycli --password=-rocks currently fails with Error: No such option: -r. Click 8.3+ sets _flag_needs_value=True on any option declared with a flag_value, which in turn triggers a parser heuristic that refuses values beginning with a dash — so the password value gets reinterpreted as short options. See #1752.

The fix wraps click_entrypoint in a small _PasswordFriendlyCommand subclass that disables the heuristic on the password option and injects the flag-value sentinel itself when -p / --pass / --password is used bare, preserving the prompt-for-password behavior. The integer sentinel becomes a unique string since injected argv values have to pass through the param type. Covered by a new parametrized test that exercises the dash-value forms (--password=-rocks, -p-rocks, --pass=-rocks, etc.) alongside the existing --password=foo, --password foo, and -procks cases to guard against regressions.

Fixes #1752.

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the AUTHORS file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[rolandwalker]

Hi! Thanks for working on this!

I have a different idea, expressed in #1842, which is to let --password be accepted by itself only in the final position. It should be simpler, and solve the dash bug. What do you think?

It seems important that the sentinel value not be a string.

[barry3406]

Hey, took a look at #1842 — your approach is cleaner, no argument there. Mine keeps bare --password working in any position and has more test cases, but yours avoids touching Click internals which is a fair trade-off. Happy to let the maintainer pick whichever they prefer.