[FEATURE]: Plugin dialog prompt needs a masked (secret) input mode #56747

The gap

DialogPromptOptions in the TUI plugin API has title, description, placeholder and value and nothing else (packages/plugin/src/tui/context.ts:348-353 at 2.0.31, 83c5abbbe3). ui.dialog.prompt (:403) therefore always echoes what the operator types. There is no way for a plugin to collect a password, token or passphrase without it showing on screen.

This is separate from #43132 (a plugin UI surface for web/desktop): even on the TUI, where plugins do get dialogs, a secret cannot be entered safely through the stock prompt.

Why we hit it

A sudo passthrough plugin: shell calls that elevate are rewritten to sudo -A, and the askpass helper has to get the password from the operator and hand it to sudo. The password must never be echoed, never reach the model, and never be written to the session. Today the only option is to build a custom masked input inside the plugin, which works on the TUI but is a lot of surface for one boolean and gives nothing on other clients.

A credential-vault plugin has the same need when enrolling a provider key interactively.

The ask

An option on the prompt dialog, something like

export interface DialogPromptOptions {
  readonly title: string
  readonly description?: string
  readonly placeholder?: string
  readonly value?: string
  readonly secret?: boolean   // render `*` per character; never echo
}

rendered as masked input in the TUI, and (once #43132 lands) in the web app with the same flag. The resolved string is returned to the plugin as today; the host should not log it or keep it in dialog state after the promise settles.

Happy to send a PR for the TUI side if the shape is acceptable.