fix(#6452): propagate org-level allowed_remote_resources to URL resolution

[fullsend-ai-coder]

Summary

Propagate the org-level allowed_remote_resources from config.yaml to all URL resolution paths, not just base: composition. Previously, policy:, agent:, skills:, plugins:, profiles:, and providers: URLs were only checked against the harness-level AllowedRemoteResources, causing confusing failures when users expected org-level trust to apply uniformly.

Related Issue

Fixes #6452

Changes

• Add OrgAllowlist []string field to resolve.ResolveOpts
• Update resolveFileURL and resolveSkillDirURL to fall back to the org allowlist when the harness-level check fails
• Pass orgAllowlist in run.go and lock.go callers when calling resolve.ResolveHarness
• Update resolveFromLock to accept and check the org allowlist during lock-file validation
• Add tests covering: policy/agent/skill resolution via org allowlist, rejection when URL is in neither allowlist, and mixed harness+org allowlist scenarios

Testing

• All new org-allowlist tests pass
• All existing TestResolveHarness_* tests pass (no regressions)
• All existing TestResolveFromLock_* tests pass (no regressions)
• go vet passes
• go build ./... passes

---

Closes #6452

Post-script verification

• Branch is not main/master (agent/6452-org-allowlist-policy-resolve)
• Secret scan passed (gitleaks — 18792930cd964497a98a4ba99d4543be13ece8a3..HEAD)
• PR body secret scan passed (gitleaks — no-git)

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:30 PM UTC · Completed 3:47 PM UTC

Commit: d6db2a5 · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Review

Findings

Medium

• [stale-doc] docs/guides/infrastructure/layered-config-reference.md:235 — The description of allowed_remote_resources says it "controls which URL prefixes are allowed for remote agent sources and base composition." After this PR, the org-level allowed_remote_resources from config.yaml also serves as a fallback for all URL resolution (policy, skills, plugins, profiles, providers), not just agent sources and base composition. The description is now narrower than the actual behavior.

Low

• [test-inadequate] internal/cli/lock_test.go — All 38 resolveFromLock test call sites pass nil for the new orgAllowlist parameter, so the org-level allowlist fallback in resolveFromLock is untested in the lock-file path. The equivalent logic is well-tested via resolve_test.go and MatchingAllowedPrefixInList has unit tests, mitigating the risk.

• [incomplete-doc] docs/guides/user/bring-your-own-agent.md:397 — The note says allowed_remote_resources "are NOT inherited from base harnesses — the child must declare its own." While still correct for base-to-child inheritance, it may mislead users: the org-level config.yaml allowed_remote_resources now provides a fallback even when the child harness omits the field.

• [stale-doc] docs/ADRs/0045-forge-portable-harness-schema.md:613 — Describes the default URL allowlist as specifically "for base composition." After this PR, the org-level allowlist also provides fallback for all URL resolution. (ADR is a point-in-time record; no update required.)

• [stale-doc] docs/ADRs/0024-harness-definitions.md:444 — The allowed_remote_resources comment lists "skills, agents, plugins, and policies" but omits profiles and providers. (Pre-existing omission not caused by this PR.)

• [field-ordering] internal/resolve/resolve.go:220 — OrgAllowlist is placed after GitToken in ResolveOpts, but before TreeFetcher in the sibling ComposeOpts struct. Minor stylistic inconsistency across packages.