Allow extensions to contribute actions to native search results (files, folders, applications)

Description

Currently, extensions can only define actions within their own command views. There is no way for an extension to contribute actions to Raycast's native search results — files, folders, and applications that appear in root search or file search.

For example, an extension like "VS Code" could add an "Open in VS Code" action to the Ctrl+K menu of any folder result, or a utility extension could add "Copy as Unix Path" to any file result. Today this is impossible — the only workaround is to build an entirely separate command that independently detects the user's context, which is a disconnected experience requiring the user to leave their current search results and invoke the extension separately.

This could work similarly to Alfred's Universal Actions system, where workflows declare action triggers that automatically appear in the action list for any matching result.

A possible API could be a new entry point type in the manifest:

{
  "actions": [
    {
      "name": "open-in-vscode",
      "title": "Open in VS Code",
      "description": "Open the selected file or folder in VS Code",
      "target": ["file", "folder"],
      "shortcut": { "modifiers": ["ctrl", "shift"], "key": "." }
    }
  ]
}

The extension's action handler would receive the selected item's path, type, and metadata — similar to how getSelectedFinderItems() works today, but integrated directly into the action panel of the result the user is already looking at.

Who will benefit from this feature?

• Extension developers can build contextual tools (IDE launchers, terminal openers, file uploaders, git actions, media converters, etc.) that integrate seamlessly into the existing search experience instead of requiring separate commands.
• End users get a unified action panel where all their tools are available in context, without needing to remember and invoke separate commands. This is one of the most-loved features in Alfred and a common expectation from users migrating to Raycast.
• Raycast itself benefits because the community can fill action gaps (like "Open in Terminal" requested in #24354, or "Open in VS Code") without the core team needing to ship each one individually.

Anything else?

Related prior discussions:

• #1064 — requested more file actions, closed as "core feature, not API." This request is different: it asks for an extension API to let the community contribute actions, not for Raycast to ship specific built-in actions.
• #24354 — a user asking for "Open in Terminal" in file search, which is exactly the kind of gap this API would let extensions fill.