deps: port perry-ext-node-forge to x509-cert 0.3 / der 0.8 (Profile is now a trait, Validity generic) #8436

This cannot merge as-is, and it is not a mechanical port

I attempted the port rather than just reporting the breakage. Findings, so the next person
does not repeat the investigation.

The lockfile bump alone is incoherent

This PR moves x509-cert 0.2 -> 0.3, which pulls der 0.8 / spki 0.8 / const-oid 0.10
into the lock — but crates/perry-ext-node-forge/Cargo.toml still declares der = "0.7",
spki = "0.7", const-oid = "0.9". The crate therefore compiles against der 0.7 types while
x509-cert 0.3 expects der 0.8, which is why der::flagset reads as "configured out" and
AsExtension appears to vanish. Bumping those three declarations in lockstep clears both of
those errors. (x509-cert is also pinned a second time in crates/perry-stdlib/Cargo.toml:417
and must move together.)

What I ported successfully

• AsExtension was decomposed into Criticality + ToExtension (refactor(x509-cert): decompose AsExtension into Criticality + AsExtension RustCrypto/formats#2109).
  Our impl AsExtension for ExtensionWithCritical becomes impl Criticality, with
  fn critical(...) renamed to fn criticality(...).
• RelativeDistinguishedName's tuple constructor is now crate-private; use the public
  TryFrom<Vec<AttributeTypeAndValue>>.
• RdnSequence's tuple constructor is likewise private; build via RdnSequence::default()
  plus the public push().

What genuinely blocks it

These are API redesigns, not renames, and they land in the certificate-building path:

1. Profile became a trait. The enum is gone, replaced by concrete profiles
   (builder::profile::cabf::Root, devid::DevId, …). Our code deliberately uses
   Profile::Manual { issuer } because — per the comment in crypto.rs — it "injects no
   extensions of its own, so the cert carries precisely what sfw requested". There is no
   drop-in equivalent; preserving that behaviour needs a custom Profile implementation.
2. Validity is now Validity<P: Profile> with private fields. The only public
   constructors are from_now(duration) and infinity(). Our code sets exact
   not_before/not_after from the caller's spec, which neither constructor expresses.
3. Name and CertificateInner field access is now private (name.0,
   cert.tbs_certificate), and CertificateBuilder::new went from 6 arguments to 4.

Recommendation

Close this PR and treat the upgrade as its own tracked piece of work. The reasons:

• cargo audit flags no advisory against x509-cert 0.2.5 — this is a routine version
  bump, not a security fix, so there is no pressure to rush it. (Contrast deps: h2 0.4.16 for RUSTSEC-2026-0258 (unbounded empty DATA frames) #8404, the h2 bump
  for RUSTSEC-2026-0258, which I merged promptly.)
• The affected code generates the CA certificates for Socket Firewall's TLS MITM. Rewriting
  certificate-profile and validity handling there against a redesigned API deserves
  deliberate work and its own review, not a dependency-bump PR.

I have filed the port as a separate issue with these findings attached.