fix(app): identify permission actions without a curated description in the dock - #60740

Issue for this PR

Closes #51519 (also covers the generic report in #50234; #59405 fixes only the shell keys, which this supersedes for unknown actions)

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When an MCP tool asks for permission, the dock shows only "Permission required" and a bare * — the action name is generated at runtime (<server>_<tool>), so the settings.permissions.tool.<action>.description lookup always misses and the description row is hidden. The request already carries the data needed to identify the ask; this renders it:

• Fall back to a readable action name (github_create_issue → "github create issue") when no curated description exists. Built-in actions are unchanged — they keep their curated keys.
• Render request.message (the permission evaluate hook can provide it) as a hint row.
• Render metadata.input (the MCP tool arguments, forwarded since fix(mcp): pass tool input as permission metadata #51062) as a scrollable mono block. Only the MCP wrapper sets metadata.input, so this never appears for built-in tools.
• TUI: show request.message under the prompt title. The TUI already had a "Call tool " fallback, so it was less broken, but it dropped the message.
• e2e regression case in session-request-docks.spec.ts pinning the readable action name, the message line and the rendered input JSON.

How did you verify your code works?

• New e2e case + the existing permission-dock regression pass (the settings.spec flake seen during a parallel grep run passes in isolation).
• bun typecheck clean in packages/app and packages/tui.

Screenshots / recordings

Pending — will attach screenshots of the fixed card for an MCP ask (readable action name, server message, tool arguments instead of only *).

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR