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, constructs a pinned URL with
integrity hash, checks the org allowlist before any outbound fetch,
and uses the existing FetchAgentHarness path for full security
validation.

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.