fix(desktop): render description on inline approval card for plugin approvals

[ethernet8023]

What does this PR do?

Fixes the desktop inline approval card showing a useless placeholder (<terminal> (plugin approval rule)) instead of the actual approval context when a plugin pre_tool_call hook escalates a tool call to the human-approval gate.

When a plugin returns {"action": "approve"}, the backend (tools/approval.py:request_tool_approval) sets the approval's command field to a synthetic label and puts the real info in description. The inline ApprovalBar only rendered command (in the "Command" expander) and never showed description, so users approved without seeing what they were approving.

Related Issue

Fixes #62402

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• apps/desktop/src/components/assistant-ui/tool/approval.tsx:
  • Render description as a context <p> line on the inline ApprovalBar (the floating fallback bar already did this)
  • Detect synthetic plugin commands (starting with <) via isSyntheticCommand and set hasCommand = false for those, hiding the "Command" toggle and the <pre> block in the "Always allow" dialog
  • Use hasCommand consistently in the "Always allow" dialog instead of raw request.command.trim()

How to Test

1. Add a pre_tool_call plugin rule that returns {"action": "approve"} for a command-bearing tool (e.g. terminal)
2. In the desktop app, trigger a tool call that matches the rule
3. On the inline approval card, the plugin's reason text (from description) is now visible as a context line
4. The "Command" toggle is hidden (the synthetic <terminal> (plugin approval rule) label is no longer shown)
5. For regular dangerous-command approvals (non-synthetic command), the description is also shown as context, and the "Command" toggle still works as before

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run tests and all tests pass (vitest run --environment jsdom — 18/18 passed)
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: NixOS (Linux)

Documentation & Housekeeping

• N/A — no config keys, docs, or tool schemas changed

[kshitijk4poor]

Thanks for the focused fix — the diagnosis is correct: plugin pre_tool_call approvals put the human-readable context in description, and the inline desktop card needs to show it.

I found two changes needed before this is ready:

1. ApprovalBar is shared by the inline card and the floating fallback. The fallback already renders request.description in its header, so the new unconditional description paragraph makes the fallback show the same reason twice. Please restrict the new paragraph to surface === 'inline', or consolidate the rendering so there is a single source of description text.

2. The synthetic-command check is too broad. request.command.trim().startsWith('<') also matches valid shell commands that begin with input redirection, such as < /dev/null command. That would hide the real command from both the Command disclosure and the “Always allow” confirmation. Please identify the specific backend-generated plugin label (<tool> (plugin approval rule)) rather than every <-prefixed command, or add an explicit field to the approval payload.

One integration note: this overlaps with #62092 in the same two files. That PR also preserves multiline descriptions and bounds long content, so please rebase or coordinate the two changes to avoid a conflicting/duplicated implementation.

The focused desktop test suite (12/12), TypeScript build, eslint, Prettier, and CI otherwise passed.