Milestone 6 (ACL/PKI): Ed25519 verify + SHA-512, built from scratch

New freestanding, verify-only Ed25519 (RFC 8032) implementation:
include/starkernel/{sha512,fe25519,scalar25519,ed25519}.h +
src/starkernel/crypto/{sha512,fe25519,scalar25519,ed25519}.c, wired into
Makefile.starkernel. Kernel never signs or generates keys -- only
ed25519_verify() is needed; signing happens in the host-side mkcapsule
build tool via libsodium/OpenSSL.

Confirmed __int128 multiply/add/shift-by-constant compile with zero
undefined symbols on all three target toolchains (only division needs
libgcc's __udivti3, per timer.c's existing documented finding -- that
file's comment updated to narrow the claim, since it had been read as
"avoid __int128 entirely"). This enabled the standard 5-limb radix-2^51
field arithmetic representation.

An abandoned first attempt (10-limb radix-2^26, avoiding __int128 out of
premature caution) hit two real bugs, both invisible on inspection and
found only by property-based testing against Python's own bignum
arithmetic: a non-uniform-radix limb misalignment in multiplication, and
a double-counted carry. Verification chain: SHA-512 against known +
boundary vectors (7/7); field arithmetic property-tested 25,045 cases;
scalar-mod-L arithmetic 300 cases (L confirmed prime via Miller-Rabin
first); full verify() end-to-end against 110 real signatures from
Python's cryptography library, including tampered inputs and the RFC
8032 S>=L malleability attack -- all correctly accepted/rejected.

Compiles clean (zero warnings) and links on all three architectures,
confirmed via the mandatory three-arch QEMU boot. The code is linked but
not yet called from anywhere -- wiring into capsule_birth.c needs a
from-scratch X.509/DER parser first (Captain Bob chose real X.509 over a
raw-blob cert format this session), which is the next open item.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HZ8kNoTuP63pbQtro4qvrm

src/starkernel/arch/amd64/timer.c

@@ -148,8 +148,15 @@ static uint64_t vm_ns_base  = 0;
  * to a double fault and then a triple fault (silently exited by
  * `-no-reboot`, which is why this looked like an infinite hang rather than
  * a crash at first). A `unsigned __int128` rewrite was tried first but
- * needs libgcc's `__udivti3` for the general 128÷64 case, undefined in this
- * freestanding, `-nostdlib` build — not viable. Fixed instead the way the
+ * needs libgcc's `__udivti3` for the general 128÷64 DIVISION case,
+ * undefined in this freestanding, `-nostdlib` build — not viable for that
+ * reason specifically. (Confirmed narrower during the Ed25519 crypto work,
+ * 2026-08-22: `__int128` multiply/add/shift-by-constant DO compile cleanly
+ * with zero undefined symbols on all three target toolchains — it's only
+ * division, needing a multi-instruction libgcc routine the compiler won't
+ * inline, that's unavailable here. Don't read this comment as "avoid
+ * __int128 entirely" — src/starkernel/crypto/fe25519.c uses it safely for
+ * exactly that reason.) Fixed instead the way the
  * Linux kernel's own `mul_u64_u64_div_u64` does it: declare `rdx` as a pure
  * *clobber*, not an output. A clobber tells GCC the register is used
  * internally by the whole asm block and must never be allocated to any