fix(ui): show queued/waiting state for tools blocked by concurrency safety

[limityan]

Problem

When multiple subagents are dispatched in a single turn and one must wait for another to finish (e.g., a read-only FileFinder followed by a read-write GeneralPurpose), the second tool previously appeared to be "running" while it was actually stuck in the tool pipeline queue. Both cards showed the same animated spinner, causing user confusion about which agent was actually executing.

Root Cause

The backend already tracks Queued and Waiting tool states and emits corresponding events, but the frontend event handler (ToolEventModule) ignored these events. Every tool card therefore transitioned directly from preparing to running, with no visual distinction for queued work.

Changes

Frontend

• ToolEventModule.ts: Add handlers for Queued and Waiting events, updating the tool card status to 'queued' / 'waiting'.
• BaseToolCard.tsx: Add 'queued' and 'waiting' to the LOADING_SHIMMER_STATUSES set and the status union type.
• DefaultToolCard.tsx: Add status text mapping for queued → "Queued" and waiting → "Waiting".
• ToolCardStatusSlot.tsx: Use a static Clock icon (instead of animated dots) for queued/waiting tools so users can visually distinguish "waiting" from "executing".
• flow-chat.ts: Extend FlowItem.status union with 'queued' and 'waiting'.
• i18n: Add localized labels for en-US, zh-CN, and zh-TW.

Agent Prompt

• general_purpose_agent.md: Add a "When to use this agent" section that clarifies GeneralPurpose is for write-heavy tasks only. Read-only research should prefer Explore or FileFinder, which can safely run in parallel.

Verification

• cargo check -p bitfun-core — pass
• pnpm run type-check:web — pass
• pnpm run i18n:audit — pass

Before / After

Before	After
Both subagents show animated dots	Queued subagent shows static clock icon
Both labeled "Executing..."	Queued one labeled "Queued" / "Waiting"
User cannot tell which is actually running	Clear visual distinction between running and waiting

Related

Fixes user-reported issue where two simultaneously visible subagents appeared parallel but only one was actually executing.