Add an `apps/` catalog for Agent Canvas Apps

Why

OpenHands Apps are installable interfaces that bring a team’s tools and workflows directly into Agent Canvas. They are powered by the Canvas Extensions API, introduced as a beta feature in Agent Canvas 1.16.

The current beta supports custom pages that appear in the Agent Canvas sidebar and can connect to the active Agent Server through its authenticated HTTP helper. This enables teams to add dashboards, internal tools, and project-specific workflows to Canvas without maintaining a fork.

We should use Apps as the user-facing category in this repository:

• It is clearer to people outside the developer audience.
• It distinguishes UI contributions from skills (agent instructions and knowledge) and plugins (agent capabilities and configuration).
• It gives the category room to grow beyond custom pages as the Canvas Extensions platform evolves.
• It aligns this registry with the Agent Canvas product language: “Apps for Agent Canvas,” “Add app,” and “Installed apps.”

Adding an apps/ directory to this registry will make community and OpenHands-built Apps discoverable alongside the repository’s existing reusable extensions. Users will have a single, familiar place to find and share skills, plugins, integrations, automations, and now Agent Canvas Apps.

Scope

• Add a top-level apps/ directory to the repository.
• Define a lightweight, documented convention for one App per directory.
• Make each App directory contain a valid Canvas Extension package, beginning with:
  • canvas-extension.json
  • its declared browser ESM entrypoint exporting activate
  • optional App-specific documentation and assets
• Add Apps to the repository’s discovery and catalog surfaces so users can browse them as they do skills and plugins.
• Use Apps as the public-facing label while accurately describing the underlying Canvas Extensions API and its beta status.
• Include clear trust guidance: Apps run trusted JavaScript inside Agent Canvas and can make authenticated requests to the active Agent Server; users should review source and resolved revision before enabling them.

Non-goals

• Renaming or moving the existing skills/, plugins/, integrations/, or automations/ catalogs.
• Expanding the Canvas Extensions API beyond the currently supported custom-page beta.
• Supporting a hosted App marketplace, remote execution, or a permission model beyond what Agent Canvas currently provides.
• Treating Apps as equivalent to agent skills or plugins.

Acceptance criteria

• The repository has a top-level apps/ directory with documented contribution conventions.
• An App can be added as a self-contained Canvas Extension package following the Agent Canvas manifest and host API contract.
• Repository documentation explains what Apps are, how they differ from skills and plugins, and how users discover/install them.
• Apps have a discoverable catalog surface consistent with the rest of this repository.
• The public copy uses the approved positioning: Apps are installable interfaces that bring dashboards, internal tools, and workflows directly into Agent Canvas without requiring a fork.
• Documentation and catalog language indicate that Apps are powered by the Canvas Extensions API and that the feature remains beta.
• User-facing trust guidance clearly states that enabling an App executes trusted JavaScript in the Agent Canvas browser context and enables authenticated requests to the active Agent Server.

This issue was created by an AI agent (OpenHands) on behalf of the user.

Start by comparing the existing skills/, plugins/, integrations/, and automations/ catalogs and their discovery surfaces. Define the top-level apps/ convention around canvas-extension.json and each App’s declared browser ESM entrypoint exporting activate, then update the relevant documentation and catalog language. Done means Apps are discoverable, their beta Canvas Extensions status is explained, and the required trust guidance is present.