Inbox pane shows Open canvas on asks and no way to the ask's chat #3714

Summary

The Workspace Inbox reading pane shows Open canvas in the header of every item, including asks, whenever the selected agent has at least one canvas. The button belongs to the agent, not to the item: on a question or approval it has nothing to do with what the person is looking at, while the one action that would help, opening the chat the ask came from, is not in the header at all.

Context

Seen on 2026-10-14 on a trinity-pm question: header "Trinity Product Manager · Question" with a lone Open canvas link on the right, above an ask that mentions no canvas. The behaviour is as designed (§3g C10: show Open canvas when there is a canvas to open), but the design gates the button on the agent's canvas count rather than on the item type. Chat threads already get Mark read / Reply in chat / Open in chat; asks get only the canvas link.

Acceptance Criteria

• On an ask item (approval, question, alert) the pane header shows no Open canvas action.
• On an ask that came from a conversation, the header offers Open in chat for that conversation, matching the thread item's action.
• Open canvas stays on thread items and on the agent rail, where the canvas already lives.
• The stacked (narrow) layout's More menu follows the same rule.

Technical Notes

• src/frontend/src/components/portal/PortalInboxPane.vue: the actions block renders Open canvas on canvasCount > 0 regardless of item.type; thread-only actions are already gated on item.type === 'thread'.
• src/frontend/src/components/portal/portalInbox.js (inboxCanvasCount) and the three portalInbox*.spec.js suites pin the current rule and will need the new one.