Define upstream registry policy for package-manager distributed CLIs

[justrach]

Parent: #251

Problem

Several high-ranked missing packages are CLIs distributed primarily through npm, pip, language package managers, taps, or vendor bootstrap installers. These should not be blindly mapped into the same trusted binary archive path without a policy.

Examples from the current top lists include:

• formulae: gemini-cli, anomalyco/tap/opencode
• casks: claude-code, codex, copilot-cli, claude

Questions to settle

• Which package-manager-distributed CLIs should nanobrew install natively at all?
• Can we resolve them to immutable tarballs with checksums, or do they require a bootstrap toolchain?
• Do they belong in formula records, cask records, or a separate resolver kind?
• What is the minimum verification story before stable promotion?
• How do we benchmark them fairly against Homebrew when Homebrew may delegate to the same package manager?

Acceptance criteria

• Document a policy in docs/upstream-registry.md.
• Add explicit allow/deny criteria for package-manager CLIs.
• Identify the first batch of package-manager CLIs that are safe to support.
• Open implementation issues for any resolver kind needed after the policy is decided.