#627 Channel-based publishing for local extension backports

Problem

When teams develop extension models locally (e.g. in a project repo under extensions/models/), backporting them into a central shared extensions repo is manual and friction-heavy. The typical flow today:

1. Develop and iterate on an extension model locally in a project repo
2. Manually copy the extension source into the central extensions repo
3. Adapt imports, tests, and metadata for the central repo's structure
4. Open a PR, run CI, fix issues that only surface in the central repo's test harness

Steps 2-4 are tedious, error-prone, and discourage contribution back to the shared repo.

Proposed solution

Add a channel-based publish + pull mechanism:

1. Publish to a dedicated channel: swamp extension push --channel staging (or --channel backport, naming TBD) publishes a local extension to a registry channel separate from the default public channel.
2. Automation watches the channel: The central extensions repo runs a scheduled job (GitHub Actions, cron, or a swamp workflow) that polls the channel for new additions or version bumps.
3. Pull and CI: When a new extension lands on the channel, automation pulls it into a feature branch in the central repo and runs the full CI suite (lint, test, bundle). If CI passes, a PR is opened automatically.

This turns a manual copy-paste-adapt cycle into: publish locally, let automation handle the port, review and merge.

Scope

• A --channel flag (or equivalent) on swamp extension push
• A corresponding --channel option on swamp extension pull so automation can target non-default channels
• Channel listing/discovery (swamp extension search --channel <name>)

Alternatives considered

• Git submodules / subtree: Ties the local repo to the central repo's git history; doesn't solve the CI validation gap.
• Manual PR workflow: What we do today. Works but doesn't scale as more teams develop local extensions.