security: require exact TLS configuration type before context creation

[seonghobae]

Buyer-visible TLS policy-integrity boundary

TLSConfiguration is an immutable reviewed TLS policy value. Accepting a subclass and then dynamically dispatching create_ssl_context() allowed subclass-controlled behavior to replace the reviewed certificate/hostname-verification path. This is a trusted configuration-integrity boundary, not a Python-sandbox claim.

Protected-main implementation

The source repair is IMPLEMENTED ON PROTECTED MAIN.

Fresh lineage:

• current protected main: 5e299de0117bd6bfd89f984acec3098565c34005;
• PR security: reconstruct exact TLS boundary on current protected main #172 (security: reconstruct exact TLS boundary on current protected main) is merged;
• exact accepted security: reconstruct exact TLS boundary on current protected main #172 source head: 3114545b1566e027c362b40c7ee2e190697eea86;
• protected merge commit: db3b0c5cef2c24addf806c4f19afa45069533d41;
• later protected-main changes retain the exact TLS-configuration boundary.

Protected behavior rejects every non-exact TLSConfiguration before subclass-controlled create_ssl_context() dispatch. Exact values and None remain supported; private trust roots, mTLS, deferred key-password handling, hostname/certificate verification, explicit TLS 1.2 compatibility, destination/DNS/proxy/request/response policy and public builders remain unchanged.

Historical PRs #112/#148/#157 are evidence only and remain superseded by the integrated #172 lineage. Historical #172 predecessor heads/checks/reviews likewise do not replace protected-main truth.

Remaining evidence debt

The product-code boundary is integrated, but organization-owned supply-chain evidence remains non-passing:

• read-only central PR ContextualWisdomLab/.github#897 is still open / mergeable / unmerged at exact head 59505c1d89eb7ea816e921b6da38079c736608c2;
• its purpose is to make unavailable Dependency Review fail closed rather than wrapper-green/skipped;
• .github is read-only from the EgressWeave writer, so no local substitute, weaker gate, duplicate workflow, credential invention, or clean-head churn is acceptable;
• after an accepted central repair reaches protected central main, require a fresh protected EgressWeave consumer candidate whose actual immutable-pinned Dependency review action executes and succeeds.

Acceptance criteria

• Preserve immutable RED evidence proving subclass-controlled TLS context creation was reachable before repair.
• Reject every non-exact TLSConfiguration before subclass-controlled dispatch.
• Continue accepting None and exact factory-created configuration values.
• Preserve TLS 1.3 default, explicit TLS 1.2 compatibility, hostname verification, CERT_REQUIRED, private trust roots, mTLS and fresh-context-per-transport behavior.
• Keep trusted TLS file/CA/certificate configuration failures actionable at construction time.
• Maintain exact owned-production coverage/package/Python/SAST evidence on the accepted implementation lineage.
• Merge the accepted repair and verify that the exact TLS-configuration boundary is retained on protected main.
• Integrate the corrected separately governed central Dependency Review repair into protected central main.
• Obtain fresh protected EgressWeave consumer evidence in which the actual pinned Dependency review action executes and succeeds; wrapper-green/skipped/predecessor evidence is non-passing.
• Close only after that end-to-end supply-chain evidence path is operationally proven; do not churn the already-integrated TLS source or create a release merely to close this issue.

Non-goals

No raw SSLContext injection API, no removal of private CA/mTLS/TLS 1.2/deferred-password support, no destination/DNS/proxy/request/response/credential/release/persistence change, no Python-sandbox claim, and no EgressWeave-local replacement for organization-owned required workflows.

[seonghobae]

Fresh state correction after protected main advanced to 1d2e19049354115776804c66b9366fad2ea5b6c5: PR #172 remains at exact head 3b87e14b72ea22cb9933e5333f7db490013b3bdd, but a fresh compare is now diverged (22 ahead / 1 behind) with merge base 52a5c6a0862e0d035b0698b79a0e8556269e0b00. No formal review or inline review thread is present on the current head. #172 was therefore returned to Draft rather than transferring the old-base CI/SAST/Security evidence across the protected-base change. The TLS exact-type source delta remains the canonical candidate; it now requires non-destructive reconstruction/revalidation on the accepted current base plus the still-unintegrated central dependency-review repair before any merge acceptance.