Introduce TrustManaging protocol for testable trust verification

[bguidolim]

Context

PR #253 fixed mcs pack update leaving inconsistent state when trust is denied. The fix includes tests for the core recovery flow, but the trust-denial path itself (promptForTrust → user denies → .skipped) cannot be tested because PackTrustManager is a concrete struct with interactive stdin prompts.

Problem

PackUpdater depends on PackTrustManager directly. Since PackTrustManager.promptForTrust() reads from stdin, tests cannot inject a "deny" or "approve" response. This leaves several paths in validateAndTrust() untestable:

• Trust denied on new/modified scripts → .skipped("update skipped (trust not granted)")
• Trust verification throws → .skipped("trust verification failed — ...")
• Stale registry recovery with scripts that need re-trusting

Proposal

Introduce a TrustManaging protocol (or closure injection) so tests can substitute a controllable trust implementation:

protocol TrustManaging {
    func detectNewScripts(currentHashes:updatedPackPath:manifest:) throws -> [TrustableItem]
    func promptForTrust(manifest:packPath:items:) throws -> PackTrustManager.TrustDecision
}

PackUpdater would accept any TrustManaging instead of PackTrustManager. Tests could then provide a mock that returns .approved or .denied deterministically.

Scope

• Sources/mcs/ExternalPack/PackTrustManager.swift — extract protocol
• Sources/mcs/Install/PackUpdater.swift — accept protocol instead of concrete type
• Tests/MCSTests/PackUpdaterTests.swift — add trust-denial and trust-approval test cases

Priority

Low — the core recovery flow is already tested. This is a testability improvement for security-relevant paths.