fix: allow Swift providers without Python privacy caps

[hankbobtheresearchoor]

Summary

Fixes the Swift provider private-text routability gate uncovered during cross-device E2E profiling against #110.

Swift providers report backend == "mlx-swift" and correctly set Python-specific privacy capability fields to false because they do not embed a Python runtime:

• python_runtime_locked=false
• dangerous_modules_blocked=false

The coordinator was still requiring those fields for all private-text backends, which made Swift providers connect, pass runtime manifest verification, pass attestation challenge verification, and appear in /v1/providers/attestation — but remain absent from /v1/models and unroutable.

This keeps the Python runtime checks for the legacy inprocess-mlx backend and uses the Swift-relevant invariants for mlx-swift:

• in-process text backend
• no proxy
• anti-debug enabled
• core dumps disabled
• env scrubbed
• runtime manifest checked
• coordinator-verified SIP

Validation

• go test ./internal/registry -run 'SwiftProvider|LegacyMLXProviderRequiresPythonPrivacyCaps|ProviderWithoutManifestCheck|ProviderPartialPrivacyCaps' -v
• go test ./internal/registry ./internal/api -v
• git diff --check

Context

This is targeted at PR #110 (swift-provider). The issue reproduced on the two-machine rig with the Swift provider on the Mac Mini: /health showed a connected provider and attestation/runtime verification passed, but /v1/models was empty until the coordinator privacy gate became backend-aware.

[vercel]

@hankbobtheresearchoor is attempting to deploy a commit to the EigenLabs Team on Vercel.

A member of the Team first needs to authorize it.