fix(saml): bump crystal-saml — namespaces + Shibboleth signature verification

[camreeves]

Steve's real-client test against UCLA Shibboleth failed with UCLA's "The login request you submitted is invalid" page on every attempt. Decoding the SAMLRequest from the redirect URL showed the AuthnRequest carried literal attributes named xmlns_samlp / xmlns_saml instead of real namespace declarations (Crystal named args cannot contain a colon), so the samlp:/saml: prefixes were unbound and OpenSAML refused the message before resolving the SP. That matches the blank "application name" on the error page. libxml2 parses the malformed XML leniently, which is why our own specs and round trips never caught it.

An audit for whatever else a real Shibboleth exchange would hit found that the response leg would have failed next, so this bump also picks up:

• C14N kept dropping whitespace-only text nodes. Shibboleth (Apache Santuario) signs SignedInfo bytes that include newline text nodes, so its signatures could never verify.
• Every serialization in the verify path used the default to_xml, which pretty-prints and injects whitespace the signer never saw. The two defects had been cancelling each other, which is why self-generated round trips always passed.
• The reference transform's InclusiveNamespaces PrefixList (Shibboleth uses PrefixList="xsd") was removed along with the enveloped Signature before the digest was computed, guaranteeing a digest mismatch.
• NotBefore / NotOnOrAfter validation ran with zero clock-skew tolerance; now 10s at the settings level, matching the legacy Ruby service's allowed_clock_drift.

All fixed on crystal-saml main (2644bd0 + 4b1bdc3 + d16bbb0) with regression specs whose expected canonical bytes are hand-derived rather than computed through the code under test. crystal-saml suite: 215 examples, 0 failures. Wire format verified end to end locally: generated a redirect URL with UCLA-shaped settings and decoded it exactly as the IdP does.

This PR is the shard.lock bump to d16bbb0. The lock entry is hand-written because shards update cannot complete on a host Crystal that fails ameba's postinstall; the entry matches what shards would write.

Before retesting on UCLA nonprod, two things to confirm on their side:

1. The adfs_strat row must have idp_cert or idp_cert_fingerprint set. auth.cr fails closed without them, and the Ruby service working proves nothing here since its fallback validator accepted whatever certificate the response embedded.
2. The SP registration at UCLA should not have an encryption certificate, since EncryptedAssertion is not yet supported. The Ruby-era registration had no SP cert so this should already be the case.

🤖 Generated with Claude Code