Feature: Signed Skill and Plugin Marketplace with Trust Policy Enforcement

## Summary

Extend Forge's skills and MCP/plugin ecosystem with a signed marketplace flow, trust policies, install provenance, and reviewable capability metadata before users install or execute external extensions.

## Problem / Opportunity

Forge supports skills, MCP connectors, and local agent/tool extensibility. That extensibility is powerful, but it needs product-level trust controls as the ecosystem grows. Users need to answer:

- Who published this skill or connector?
- What files, tools, network endpoints, and permissions can it affect?
- Has the package changed since I installed it?
- Can I pin, audit, update, or remove it safely?
- Which extensions are allowed in offline-safe or strict environments?

Without a signed marketplace and trust policy model, extension growth could weaken Forge's security posture.

## Proposed Feature

Build a trust-aware marketplace and installation workflow:

- Extension manifest schema for skills, plugin bundles, MCP connection templates, and optional agent/tool metadata.
- Signature verification for marketplace entries and downloaded bundles.
- Install provenance records with source URL, digest, publisher, signature status, installed version, and capabilities.
- Trust policy controls that can allow, warn, or block extension install/use based on source, signature, permission class, network behavior, or sandbox needs.
- CLI and dashboard flows for search, inspect, install, update, pin, remove, and audit.
- Documentation for publishing and reviewing extensions.

## Scope

Expected implementation areas:

- `src/skills/loader.ts` and `src/skills/marketplace.ts` for manifest, install, and provenance behavior.
- `src/mcp/registry.ts` and `src/mcp/client.ts` for MCP connection capability metadata.
- `src/permissions/risk.ts` and `src/permissions/manager.ts` for extension-driven trust policy checks.
- `src/release/verify.ts` as a possible reference for signature/digest verification patterns.
- `src/cli/commands/skills.ts` and `src/cli/commands/mcp.ts`.
- Dashboard endpoints/views in `src/ui/server.ts` and `src/ui/public/`.
- Docs for marketplace publishing, trust policy, and offline installs.

## Acceptance Criteria

- [ ] Marketplace entries expose machine-readable capability metadata before installation.
- [ ] Installed extensions record provenance, digest, version, source, signature status, and capabilities.
- [ ] Users can pin an installed extension to a version or digest.
- [ ] Trust policy can block unsigned or unknown-source extensions before install or use.
- [ ] CLI and dashboard can inspect installed extensions and show whether they are trusted, pinned, outdated, or modified.
- [ ] MCP templates declare expected transport, auth mode, endpoint/command shape, and tool namespace.
- [ ] Tests cover manifest validation, provenance persistence, signature failure, policy block, and update behavior with mocked network/file inputs.
- [ ] Documentation includes a publisher checklist and an operator review checklist.

## Non-Goals

- Hosting a centralized commercial marketplace.
- Guaranteeing that signed extensions are safe, only that provenance and policy are enforced.
- Allowing extensions to bypass Forge's existing permission system.
- Replacing project-local skills for advanced users.

## Dependencies / Risks

- Manifest schema must be stable enough for future tooling but small enough to adopt quickly.
- Signature verification should reuse existing release verification concepts where practical.
- Capability metadata can drift from actual behavior unless install/use-time checks enforce it.
- Network access for marketplace search/install must be explicit and permission-gated.

## Open Questions

- Should Forge maintain an official default registry, or only support user-configured registries initially?
- Should extension signatures use the same key model as release manifests?
- What should happen when an installed extension's files are locally modified?
- Should trust policy be global, project-local, or both?