[bug] Render resolved permission outcomes instead of generic Continued

[zerob13]

Summary

Resolved tool-permission action blocks are rendered with the generic label Continued regardless of whether the request was granted or denied. The resolution should be shown as part of the associated tool card using the actual persisted outcome.

Priority: P1

Current behavior

The runtime correctly records permission resolution:

• granted request: block.status = 'granted' and grantedPermissions is populated;
• denied request: block.status = 'denied' and the request is no longer actionable.

See markPermissionResolved() in
src/main/agent/deepchat/runtime/interactionProjection.ts and the equivalent streaming helper in src/main/agent/deepchat/runtime/process.ts.

src/renderer/src/components/message/MessageBlockAction.vue does not inspect that outcome. Apart from rate-limit and legacy needContinue branches, every resolved action renders the same checkmark and components.messageBlockAction.continued string.

As a result, a denial can be visually described as “Continued.” Dedicated granted/denied i18n strings already exist but are not used by this component.

Related contracts and documentation

• docs/architecture/tool-system.md defines one main-process ToolPermissionBroker as the authority for host-tool consent.
• docs/architecture/session-management.md requires renderer and other entry points to share one permission semantic rather than invent independent meanings.
• docs/architecture/local-control-plane/spec.md treats approval result and redacted presentation as a typed state-machine outcome.

The renderer should faithfully project the broker-owned decision.

Impact

• Users cannot tell whether they approved or rejected a tool after the interaction closes.
• “Continued” describes control flow, not the security decision the user made.
• Denial history can be actively misleading.
• The separate action card adds visual noise and is disconnected from the tool whose execution it controls.

Proposed experience

Before
[check] Continued
[Run command ...]  Completed

After grant
[Run command ...]  Allowed -> Running -> Completed

After denial
[Run command ...]  Denied  [Retry]

• Merge the resolved permission status into the associated tool card where possible.
• Use subtle Allowed / Denied labels derived from block.status.
• Preserve an audit trace without rendering a second large action card.
• Keep unresolved permission controls and read-only history behavior unchanged.

Acceptance criteria

• Granted requests render as Allowed/Granted, never Continued.
• Denied requests render as Denied and cannot appear successful.
• The status is associated with the correct tool call.
• Pending permissions remain actionable and accessible.
• Question actions and legacy continue actions retain their distinct semantics.
• Renderer tests cover pending, granted, denied, read-only, and missing-tool-card fallbacks.

User benefit

Permission history becomes accurate, compact, and trustworthy. Users can understand exactly what they allowed without reconstructing it from later tool behavior.