Let plugins add actions to file context menus

[brsbl]

Problem

Plugins can't add actions to bb's file context menus. In the file-link menu (ExperimentalFileLinkMenu), the only plugin contribution is a file opener under Open with ▸, matched by extension. File tabs in the side panel and chat file links offer no plugin entry at all. So any plugin action that applies to "this file" needs its own picker or command, away from where users actually meet files.

Use cases

• Open elsewhere: open in an external app on the file's host, reveal in Finder or a file manager (see Add a Finder action beside local file links #1634), open in an editor.
• Hand to agents: send to a new thread, ask the agent about this file, attach to the composer.
• Transform or inspect: convert, format, show history or diff, summarize, by running a plugin command against the file.
• Collect: add the file to a plugin-owned list, context bundle or docs vault.
• Share: copy as a Markdown link, upload or share via Connect.

Proposal

One additive SDK contribution point for file actions, used by every file context menu:

• Registration: a plugin registers actions with a label, an optional icon, an optional predicate (file vs folder, extension, host or platform, thread scope, availability) and a handler. The handler receives the file target (hostId, path, kind) plus the current thread and environment, if any.
• Surfaces:
  • chat file links;
  • experimental_FileLink;
  • side-panel file tabs;
  • file-tree rows where they exist.
• Placement: actions go in a plugin section after bb's own items. They're grouped by plugin, with overflow into a submenu past a small limit, keyboard accessible, and hidden when the predicate fails.
• Compatibility: existing menus, openers and plugins behave exactly as before.

Workaround today

Registering a fake file opener shows up as Open with ▸ . That misuses the opener slot, covers only the listed extensions, and hides actions in a submenu, so it isn't a real substitute.

[bb-slop-cop]

🚨 SLOP COP 🚨 · new-issue-autopilot

Applied missing classification:

• Type: Feature
• Priority: Medium
• Effort: High
• Labels: plugins, ui

This adds a public SDK contribution point across file-menu surfaces rather than correcting unexpected behavior. Medium priority reflects the existing picker/opener workarounds; High effort reflects the new extensibility contract and multi-surface integration. No existing classification values were replaced; all applied values were verified.

Reproduction report and fix skipped because the final Type is Feature. No pull request: this requires product/API design, not a simple bug fix.

AGENT GENERATED