feat(cli): add runtime fallback to agents repo for unconfigured agents

When an agent is not registered in config.yaml, resolveAgentSource now
attempts to fetch the latest harness from fullsend-ai/agents before
falling back to the scaffold-embedded harness on disk.

The fallback resolves the main branch HEAD SHA via the forge.Client
interface, validates the SHA format, checks the org allowlist before
any outbound fetch, and caches the fetched content directly. Supply-
chain integrity relies on commit-pinned URLs, TLS transport, and the
org allowlist.

Only known first-party agents (triage, code, fix, review, retro,
prioritize) are eligible for fallback; the fallback is skipped in
offline mode or when no forge client is available. This is a
transitional mechanism for the agent extraction
(docs/plans/agent-extraction-to-agents-repo.md) and will be removed
once all users have migrated to config-driven registration (ADR 0058
Phase 5).

Signed-off-by: Greg Allen <gallen@redhat.com>
Signed-off-by: Claude <noreply@anthropic.com>
Signed-off-by: Greg Allen <gallen@redhat.com>

Author: ggallen

docs/ADRs/0058-agent-registration.md

@@ -78,6 +78,7 @@ phasing, schema details, CLI behavior, and migration mechanics.
 - The additive merge model allows agents to be extracted from the scaffold one at a time without disrupting existing installations.
 - Per-repo installs no longer need org config for remote resource validation.
 - No forced migration — empty config falls back to scaffold discovery until populated.
+- **Transitional agents-repo fallback:** During the [agent extraction](../plans/agent-extraction-to-agents-repo.md), a runtime fallback resolves known first-party agents from `fullsend-ai/agents` when not in config. This avoids requiring config changes from existing users during extraction. The fallback will be removed once all users have migrated to config-driven registration (Phase 5 / extraction plan Step 7).
 - The `agents` YAML key was previously used in `OrgConfig` with a different schema (role/name/slug identity tuples, removed by ADR 0045 Phase 4). The new schema (URL/path source entries) is incompatible; a custom unmarshaler detects and rejects old-format entries with a clear error message.
 
 ## References

docs/architecture.md

@@ -240,7 +240,7 @@ Fullsend provides a base set of agent definitions. The adopting organization's *
 **Decided:**
 
 - Config-level agent registration: an `agents` list in both `OrgConfig` and `PerRepoConfig` declares agent harness sources as pinned URLs or local paths, replacing compiled-in agent discovery ([ADR 0058](ADRs/0058-agent-registration.md)).
-- Runtime resolution: `fullsend run <name>` looks up the agent in config and loads the harness directly from the URL or path — no intermediate wrapper files on disk. Role and slug come from the harness content itself.
+- Runtime resolution: `fullsend run <name>` resolves agents in three tiers: (1) config entries from `OrgConfig.Agents` (highest priority), (2) runtime fallback to the `fullsend-ai/agents` repository for known first-party agents not in config, (3) scaffold-embedded harnesses on disk. The agents-repo fallback is a transitional mechanism for the [agent extraction](plans/agent-extraction-to-agents-repo.md); it will be removed once all users have migrated to config-driven registration (ADR 0058 Phase 5).
 - Additive merge: config entries overlay scaffold-discovered agents (config wins on name collision), enabling gradual extraction of first-party agents without disrupting existing installations. Builds on [ADR 0045](ADRs/0045-forge-portable-harness-schema.md) harness identity model.
 - CLI management: `fullsend agent add/list/update/remove` manages config entries and auto-pins URLs to a commit SHA with an integrity hash.