fix(security): harden remote-URL & runtime-arg validation; honest keychain notice (M4/M5/I1)

[m1ngshum]

Summary

Pre-existing hardening surfaced by the post-ship security review (companion to #65, which fixes the shipped-diff gaps). These are not regressions from #62/#61/#63/#64 — they predate them — but they're worth closing.

Findings fixed

ID	Sev	What	Fix
M4a	MED	validateRemoteUrl accepted plaintext http:// to any host; once written to an IDE config it's interceptable. The mcpm up URL-server path also wrote stack-file url: servers unvalidated.	https always allowed; http only for loopback (localhost / 127.0.0.1 / ::1 / *.localhost). validateRemoteUrl is now also called on the up URL path.
M4b	MED	validateRuntimeArgs' allowlist permits . and / in values, so a .. traversal segment (e.g. --config=../secret) slipped through to the spawned server.	Reject a .. path segment up front — bare, after =, or path-separated. A non-traversal double-dot like --range=1..10 is left alone.
M5 / I1	LOW/INFO	The keychain storage notice claimed "protects against other-user/offline access" unconditionally — false when keychain mode silently falls back to the machine-derived key.	Notice is now honest about both backends and points to mcpm secrets migrate.

Tests

• M4a: http:// to non-loopback hosts rejected; loopback http + all https allowed.
• M4b: bare .., a/../../b, --config=../secret, --config=../../secret rejected; --range=1..10 allowed.
• Full vitest suite green; tsc --noEmit + tsup clean.

Deliberately NOT changed (with rationale)

• L2 (macOS argv master key): security(1) has no clean non-interactive stdin path; the maintainer already documented this as an acceptable, narrow same-user window (os-keychain.ts). Overriding a reasoned decision with a breakage-prone change isn't warranted.
• Guard relay: flagged for a dedicated deep review (out of scope here).

[m1ngshum]

Multi-agent review pass — addressed (commit 0984949)

Verdict was request-changes (no security bypass, but a real regression + a coverage gap). Both fixed:

• MEDIUM dry-run regression — validateRemoteUrl ran before the dry-run guard in processUrlServer, so mcpm up --dry-run on a bad stack URL threw and exited non-zero on a read-only pass. Now captures the result instead of throwing: dry-run previews it as would reject URL … (exit zero); a real run categorizes the bad URL as blocked (mirroring trust-policy blocks) instead of a generic failed.
• HIGH coverage gap — the up-path URL validation had zero integration tests. Added four handleUp cases: valid https installs to Cursor, non-loopback http blocked, non-http(s) scheme blocked, and the dry-run regression itself.
• Nits: added an IPv6 bracket-loopback test (http://[::1]:8080 — the bracket-strip is load-bearing); documented that isLoopbackHost intentionally over-rejects exotic loopback spellings (never a bypass).

Note: the disputed "M4b regex character-class bug" was verified a false positive — the class includes a literal backslash, so a\..\b and ../x both match while 1..10 is correctly allowed.

Full suite green (1302), tsc + tsup clean.