fix(kernel): enforce the RFC 4861 hop-limit gate before NDP touches the cache

[kernalix7]

Audit of crates/kernel/src/ipv6.rs ahead of wiring it into net.rs, per the
crates/kernel/AGENTS.md rule that an unwired parser must be audited before it
becomes attacker-reachable.

Audit result

The two classes the audit targeted came back clean:

Class	Finding
Overflow / underflow	Clean. opt_len_units * 8 ≤ 2040; IPV6_HEADER_LEN + payload_length ≤ 65575; the checksum accumulator peaks near 2.15e9 against a u32 ceiling of 4.29e9.
Unbounded loop	Clean. parse_ndp_options advances ≥ 8 bytes per iteration (a zero length breaks out); the checksum loop advances by 2 on the skip branch as well as the normal one.

Both were already hardened by earlier passes. The defect is elsewhere.

The defect

RFC 4861 §7.1.1 and §7.1.2 require a Neighbor Solicitation or Advertisement to
be discarded unless the IP hop limit is 255. That one rule is what confines
NDP to the local link — 255 is the maximum a sender can set and every router
decrements, so a message still carrying 255 provably never crossed one.

hop_limit was parsed, stored and serialized, but never read on the receive
path:

$ grep -n hop_limit crates/kernel/src/ipv6.rs
189:    pub hop_limit: u8,        # struct field
209:    let hop_limit = data[7];  # parse
259:    buf[7] = self.hop_limit;  # serialize
...                              # remainder: send-side constants only

This is not theoretical. NeighborTable::handle_advertisement already
implements the §7.2.5 Solicited/Override rules specifically to stop
neighbor-cache poisoning, and its SECURITY comment describes the on-link MITM
it prevents. Those rules assume the sender is on the link. Without the
hop-limit check that assumption is unfounded, so an off-link attacker — anywhere
routable — could drive the cache into exactly the state the §7.2.5 work was
written to prevent.

The ICMP code field was likewise never validated, and handle_neighbor_advertisement
accepted a multicast target.

Fix

• ndp_message_is_valid, applied to the NS and NA arms of handle_icmpv6
  before either handler runs: hop limit 255 and code 0. Echo request/reply are
  deliberately not gated — the rule is specific to NDP.
• Reject an NA whose target is multicast (§7.1.2). The target names the address
  being resolved, so a multicast value identifies no neighbor and only serves to
  steer an entry the sender does not own. The NS path already rejects these
  implicitly by requiring the target to equal our own address.
• Both send paths now use the same NDP_HOP_LIMIT constant they were
  hardcoding, so transmit and receive cannot drift apart.

Tests

Six added. Four fail without the fix:

ns_that_crossed_a_router_is_dropped              FAILED -> ok
ns_with_nonzero_code_is_dropped                  FAILED -> ok
na_that_crossed_a_router_cannot_touch_the_cache  FAILED -> ok
na_for_multicast_target_is_dropped               FAILED -> ok

Two guard the legitimate path and pass both before and after —
ns_at_hop_limit_255_is_still_answered and na_at_hop_limit_255_still_resolves.
That pairing is what shows the gate rejects forged messages rather than all of
them.

The shared ndp_packet helper always writes a correct checksum, so acceptance
turns solely on the field under test rather than on the existing checksum gate.

Verification

• cargo fmt --all -- --check
• cargo clippy --workspace -- -D warnings
• cargo build --workspace
• cargo build -p oncrix-kernel --bin oncrix-kernel --target aarch64-unknown-none
• cargo build -p oncrix-kernel --bin oncrix-kernel --target riscv64gc-unknown-none-elf
• bash scripts/run-tests.sh — 4593 passed, 0 skipped (kernel 353 → 359)

Follow-up

Wiring ETHER_TYPE_IPV6 into the net.rs ethertype match is deliberately left
to a separate PR, so the validation lands before the surface becomes reachable.