Add direct client peer discovery

[magiccodingman]

Summary

Fixes the missing standalone application-discovery path in MagicControl.Client and completes the intended open-to-secured runtime transition.

Direct client discovery

• discovers ordinary applications directly on the LAN with no Web, Mesh API, or cached signed directory
• signs advertisements with the existing persistent MagicSettings identity
• validates body hash, proof target, audience, method, lifetime, identity, fingerprint, endpoint policy, and ECDSA signature
• stores observations in a separate encrypted, short-lived peer cache
• returns unmanaged standalone peers as IdentityVerified, never authority-approved
• upgrades direct peers to AuthorityApproved only when a usable signed secured manifest contains the exact approved credential
• filters unapproved peers under secured policy

Runtime open-to-secured behavior

• applications begin in open/additive mode before any signed Secured policy is accepted
• [RequireMagicControlMember] and [RequireMagicControlCapability(...)] become secured dynamically after approval without restarting the process
• inbound authorization and outbound service resolution switch together
• approval closes the in-memory gate immediately and persists a non-secret secured-policy.lock marker
• once secured, outages, restarts, missing/corrupt ordinary state, missing manifests, expired finite leases, and new unmanaged peer advertisements cannot reopen the application
• a known secured application never downgrades to identity-only routing
• only a successfully validated signed authority manifest explicitly declaring Open may clear the latch
• opening is crash-safe: the signed Open manifest is durably saved first, then the latch is removed, then the in-memory gate is relaxed
• moving to another authority is never inferred from connectivity loss; it requires an explicit trust reset and re-enrollment decision

Standalone behavior

App A + App B
No Web
No Mesh
No signed cache
No prior secured policy

→ both advertise signed endpoints
→ both verify the other's MagicSettings identity
→ IMagicControlServiceResolver returns IdentityVerified routes
→ MagicControl-protected endpoints remain open

After either application accepts a signed Secured policy:

approved exact credential → AuthorityApproved route and authenticated access
unapproved identity       → filtered/denied
missing authority state   → fail closed, never reopen

Validation

GitHub Actions passes on the completed implementation:

• restore
• Release build
• complete test suite
• MagicControl.Client NuGet pack
• package-content validation

New coverage includes:

• advertisement signature validation and tamper rejection
• identity-only resolution before authority enrollment
• rejection of unapproved peers under secured policy
• exact approved-peer upgrade
• finite secured-lease expiry remaining fail-closed
• encrypted peer-cache persistence and signature revalidation
• live open-to-secured authorization transition without restart
• persisted secured latch surviving restart and corrupted ordinary state
• secured latch blocking identity-only service resolution when no manifest exists
• validated signed Open state clearing the latch