display_command profile resolver doesn't rename invocation argv in normal production use, contradicting its own docs

[codeforester]

Summary

docs/consumer-profiles.md claims a wrapper's display_command label is retained in "invocation metadata," but in the standard production entry point it isn't — only in an explicit-argv (mainly test/embedding) code path.

Details

• docs/consumer-profiles.md:89-90 states that passing delegated_display_command as a profile's display_command resolver makes a wrapper's label retain "in lifecycle-facing usage and invocation metadata."
• lib/python/base_cli/app.py:2743 (explicit_argv = argv is not None), :2762-2763, and _effective_invocation_argv (:3038-3046) only substitute display_command for argv[0] when run_app() is called with an explicit argv argument.
• In the standard production entry point (raise SystemExit(base_cli.run_app(app)), argv=None), it returns raw list(sys.argv) unmodified, so display_command only affects Click's prog_name (help/usage/version text) — not the argv recorded in DEBUG logs (log_invocation) or passed to history_writer/build_finished_record's argv field.

Impact

This is exactly the "launcher" scenario the doc describes as fully supported, and it isn't — a consumer relying on the documented behavior for log/history redaction of their wrapper name will find the real underlying argv[0] still present in logs and history.

Suggested fix

Either update the doc to clarify the scope (usage/help text only) or make _effective_invocation_argv substitute display_command for argv[0] regardless of explicit_argv.