ESP32 TLS to Seed fails: Device CA Name Constraints use iPAddress subtrees (mbedTLS -0x2562)

Ok, so the stack-overflow fix (#949) works. But I hit another issue after cycling through
the following omissions from the bare sdkconfig.defaults:

1. CONFIG_ESP_TLS_INSECURE / SKIP_SERVER_CERT_VERIFY - the Seed cert is
   self-signed and swarm_bridge.c attaches no CA; under IDF v6.0 this is fatal
   (0x8017). Proper fix: embed the Cognitum Device CA via crt_bundle_attach
   rather than skip-verify.
2. CONFIG_MBEDTLS_SSL_PROTO_TLS1_3 (+ MBEDTLS_PSA_CRYPTO_C dependency) - the
   Seed is TLS 1.3-only; the default build is TLS 1.2-only.
3. CONFIG_SPIRAM (+ MBEDTLS_EXTERNAL_MEM_ALLOC) - PSRAM disabled, so the node
   ran out of internal RAM (sendto ENOMEM).

With all of the above set, the handshake still failed -0x0062 regardless of TLS
version, PSRAM, mbedTLS 3.6 vs 4.x, or SNI/hostname.

The root cause found : decoding the chain pins it to the
Cognitum Device CA certificate, which has a critical Name Constraints
extension containing iPAddress subtrees (IP:169.254.0.0/255.255.0.0,
IP:127.0.0.0/255.0.0.0). mbedTLS's Name Constraints parser does not support
iPAddress subtrees and returns MBEDTLS_ERR_X509_INVALID_EXTENSIONS +
MBEDTLS_ERR_ASN1_UNEXPECTED_TAG (-0x2562). It's critical (can't skip) and
parsed before verification (skip-verify can't bypass). OpenSSL/Python support IP
name constraints, so the host bridge connects fine. Fix: regenerate the Device
CA without the IP: name constraints (or drop the Name Constraints extension).

Nice to have - fold ESP_TLS_INSECURE/SKIP_SERVER_CERT_VERIFY (or, embed the
Cognitum Device CA via crt_bundle_attach), MBEDTLS_SSL_PROTO_TLS1_3 (+ PSA),
and SPIRAM/MBEDTLS_EXTERNAL_MEM_ALLOC into the shipped sdkconfig.defaults -
the bare-defaults Docker build currently omits all of these.

Deployment questions (for applying the cert fix to a live Seed)

Once the new cert is available, can you please confirm:

1. Delivery - does the cert fix ship as a Seed software/firmware update, and
   how is it applied?
2. Regeneration - does the certificate auto-regenerate on update, or is there
   a command / re-provision / PKI-reset step to re-issue the CA + device cert?
3. Identity rotation - does regenerating the CA change the Seed's device
   identity and invalidate existing pairing tokens (i.e. do I then need to re-pair the
   bridge / Synapse and reissue SEED_TOKEN)?
4. Witness chain - does the regeneration touch custody / the witness chain, or
   is the audit anchor preserved across the cert rotation?

Hopefully that is enough info, let me know if you need more.

Start with sdkconfig.defaults and swarm_bridge.c, then trace the Seed certificate delivery and regeneration path described in the issue. Verify the shipped defaults cover the listed TLS, certificate, and memory requirements, and confirm a live Seed can complete the handshake with a CA that omits the unsupported iPAddress constraints. Record how updates, identity rotation, pairing tokens, and the witness chain are affected.