Simple ciphers: stream + symmetric cipher unification off the release branch, plus SHA-512/t for any t

[dghgit]

Consolidates the stacked pair #113 (feature/stream-cipher → release/0.1.3alpha) and #115
(feature/symmetric-cipher → feature/stream-cipher) into a single branch off the release
branch, and adds the SHA-512/t work on top.

feature/simple-ciphers was built by branching from release/0.1.3alpha and merging
feature/stream-cipher then feature/symmetric-cipher; both merges fast-forwarded, so the
content below the two new commits is exactly what #113 and #115 already carried — this is a
re-packaging, not new review surface. #113 (+21,938) and #115 (+2,310) sum to roughly the
+23,499 here.

New in this PR, on top of those two

core: SecurityStrength::from_bits / from_bytes become const fn (3912434) — two
keywords, no behaviour change. Needed so an associated const can derive a strength from a const
generic; split out ahead of the feature per CLAUDE.md's scope-of-changes rule.

sha2: SHA512t<T> is usable for every t FIPS 180-4 s. 5.3.6 defines a hash for (785dbef).
Previously only T = 224 and T = 256 had parameter impls, so nothing else could be named.

• The t-value checks are back, and they are the spec's. b11f8f6 had narrowed sha512t_h0 to
  100 <= t < 512 and emitted a fixed three digits, since only 224 and 256 were reachable. With
  arbitrary t reachable that would produce the "0256" spelling s. 5.3.6 explicitly forbids —
  and hence the wrong IV — for every t below 100. The one- and two-digit branches are restored
  and check_t asserts the section's own rule: positive, < 512, not 384.
• One deviation, documented: t must be a multiple of 8, because Hash is byte-oriented and
  a 100-bit digest has no representation here. BC Java's SHA512tDigest imposes the identical
  restriction, so the two libraries accept the same set of truncations.
• Unapproved truncations are gated the way ElectronicCodeBook::ENCRYPTION_APPROVED gates
  two-key TDEA: SHA512tParams::<T>::FIPS_APPROVED is public and SHA512Internal::new asserts it
  in an inline const, so an unapproved t is a compile error at the call site and
  new_allow_unapproved_t() is the deliberate way in. That also blocks Default, which keeps an
  unapproved truncation out of generic code by accident.
• ALG_NAME, OUTPUT_LEN and MAX_SECURITY_STRENGTH are derived from t, with const
  assertions pinning them to the values 224 and 256 previously had by hand.

Verification

• cargo test --workspace: 943 passed, 0 failed (was 923). cargo fmt --check clean; no new
  clippy warnings. Both new commits build independently.
• Spec text read from a freshly downloaded FIPS 180-4, not from recall.
• Test vectors cross-checked against BC Java's SHA512tDigest, an independent implementation:
  eight truncations (8, 16, 24, 88, 96, 104, 264, 504) spanning all three decimal branches, over
  the FIPS 180-4 Appendix C messages plus the one-million-'a' case. The 224/256 rows in the same
  table match the NIST-published values.
• cargo mutants on the changed files: 259 mutants — 180 caught, 5 timeout-kills, 69 unviable,
  5 missed. All five missed are the pre-existing XOR/OR equivalences already annotated at their
  sites in ch, maj and do_final_internal; no new missed mutants.

Note for reviewers

Adding const to a public core function is a forward compatibility commitment, and
SHA512tParams is currently its only caller. The alternative was a private copy of the rounding
ladder inside sha2, free to drift from the real one — happy to switch if the API-surface cost is
the greater worry.

🤖 Generated with Claude Code

[ounsworth]

Note-to-self: leaving un-viewed until I check the ascon bits

[ounsworth]

We have provided a do_encrypt_out, but not a do_encrypt() -> Vec<u8>. Create one, wrapped in a #[cargo(alloc)]` that we can clean up later after Jason's pattern lands.

[ounsworth]

Ditto for the AEAD trait -- most of the things there needs to be twinned.

[dghgit]

Sure, anything like this, feel free to add.