Feature: Portable Team Bundles for Config, Skills, Policies, MCP Templates, and Verification Standards

## Summary

Add portable team bundles that package Forge configuration, skills, policy profiles, MCP templates, verification standards, and documentation into reviewable artifacts teams can import, audit, and update consistently across projects.

## Problem / Opportunity

Forge is local-first and configurable: it has global/project config, skills, MCP connections, permissions, modes, validation, and docs-driven workflows. Teams that want consistent behavior across repositories need a way to distribute standards without asking every developer to manually copy files or settings.

Examples:

- A team wants every repository to use the same verification chain.
- A security-sensitive project wants a strict policy profile and MCP allowlist.
- A group wants shared skills for release, debugging, and review workflows.
- New contributors need a one-command bootstrap for local Forge conventions.
- A team wants to review changes to Forge operating standards as code.

## Proposed Feature

Introduce portable team bundles:

- Bundle manifest with config overlays, skills, policy profiles, MCP connection templates, verification commands, docs references, and optional sample prompts.
- `forge bundle create` and `forge bundle install` extensions focused on team standards, not only offline install payloads.
- Import preview that shows exactly what will change before applying.
- Redaction and secret placeholders for MCP/API configuration.
- Versioning, compatibility checks, and rollback metadata.
- Dashboard support for inspecting installed bundles and drift from bundle baselines.

## Scope

Expected implementation areas:

- Existing `src/cli/commands/bundle.ts` as the user-facing command surface.
- `src/config/schema.ts`, `src/config/loader.ts`, and `src/config/paths.ts` for importable overlays.
- `src/skills/loader.ts` and `src/skills/marketplace.ts` for bundled skills.
- `src/mcp/registry.ts` for templated connections that do not embed secrets.
- `src/permissions/manager.ts` and future policy profile support for permission standards.
- `src/security/redact.ts` for bundle preview/export safety.
- Docs in `docs/SETUP.md`, `docs/CLI-REFERENCE.md`, and an operator guide.

## Acceptance Criteria

- [ ] Users can create a bundle manifest from selected local Forge settings and project conventions.
- [ ] Users can preview bundle installation before changes are applied.
- [ ] Bundle install never writes secrets; API keys and OAuth secrets are represented as placeholders or post-install prompts.
- [ ] Installed bundle metadata records source, version, digest, installed files/settings, and rollback information.
- [ ] Drift detection shows local changes from the installed bundle baseline.
- [ ] Bundles can include skills, config overlays, policy profiles, MCP templates, and verification command recommendations.
- [ ] Tests cover manifest validation, preview diffs, redaction, install rollback metadata, and compatibility errors.
- [ ] Documentation includes a team onboarding example and a bundle authoring checklist.

## Non-Goals

- Centralized remote device management.
- Automatically granting dangerous permissions during install.
- Storing real credentials in bundle files.
- Replacing repository-specific `AGENTS.md` or `CLAUDE.md`; bundles should complement them.

## Dependencies / Risks

- Bundle overlays must have clear precedence relative to global and project config.
- Secret handling must be conservative and reuse existing redaction/keychain patterns.
- Bundle installs can affect developer workflows, so preview and rollback metadata are important.
- Compatibility checks need to account for Forge version and manifest version.

## Open Questions

- Should bundle manifests be YAML, JSON, or both?
- Should installed bundles be project-local, global, or selectable per run?
- Should drift detection be read-only in the first version?
- How should bundle updates handle local user modifications?