feat: scheduled wakeup primitive for delegates (ScheduleWakeup / WakeupFired)

[sanity]

Problem

Delegates have no way to schedule future execution. The OutboundDelegateMsg
enum has no ScheduleWakeup-equivalent variant and InboundDelegateMsg has no
WakeupFired, so delegate execution is purely message-driven. dApps that need
periodic background work (key rotation, TTL pruning, scheduled publication) are
forced to push it into a UI/client sync loop, which stops working when the UI is
closed. Driving use case: River private-rooms weekly secret rotation
(freenet/river#228).

Approach

Add the two wire variants the host↔delegate protocol needs:

• OutboundDelegateMsg::ScheduleWakeup { at: SystemTime, tag: Vec<u8> }
• InboundDelegateMsg::WakeupFired { tag: Vec<u8> }

Both are appended at the end of their enums (bincode variant tag 8), so the
change is wire-compatible for every existing variant — delegate WASM compiled
against an older stdlib keeps deserializing everything it already understood.

• OutboundDelegateMsg is deliberately left not #[non_exhaustive]: the
  host must consciously handle every outbound variant, so the compiler should
  force an arm for each new one. The inaccurate doc comment on
  InboundDelegateMsg that claimed OutboundDelegateMsg was already
  #[non_exhaustive] is corrected.
• InboundDelegateMsg stays #[non_exhaustive]; unknown inbound variants are
  forwarded to the delegate WASM unchanged, so WakeupFired flows through.
• These variants travel only on the bincode host↔delegate FFI path, not the
  FlatBuffers WS path, so no .fbs schema / generated-code / TypeScript changes
  are needed. ScheduleWakeup gets a "reached client serialization - this is a
  bug" arm in the WS encoder mirroring SendDelegateMessage.

Bumps 0.8.2 → 0.8.3.

Testing

New wire-format pin tests freeze the variant tags so a future reorder is caught
loudly:

• inbound_wakeup_fired_wire_format_is_stable — full byte layout at tag 8.
• outbound_schedule_wakeup_wire_format_is_stable — tag 8 + round-trip.

Downstream

Host-side implementation is in freenet-core#3972 (opens after this publishes,
per the stdlib-first release policy).

Refs: freenet/freenet-core#3972

[AI-assisted - Claude]

[sanity]

Host-side consumer: freenet/freenet-core#4666 (issue #3972). This stdlib PR must merge + publish 0.8.3 first (stdlib-first), then the core PR can build.

[AI-assisted - Claude]

[sanity]

Coordination note for whoever picks this up: tag 8 is now taken, and this PR needs to move to 9.

Delegate unsubscribe (UnsubscribeContractRequest / UnsubscribeContractResponse, closing the half of #2830 that was specified but never built) is landing in #98 and appends to these same two enums. Both changes wanted the next free tag. @sanity settled the ordering: unsubscribe takes 8, this PR rebases onto it at 9.

Why it needed settling rather than being left to merge order: these enums are bincode-encoded with the variant index in declaration order, so two independent "append at the end" changes silently renumber each other. Nothing caught that before — #98 adds a pin asserting the tag of every variant in both enums, backed by an exhaustive match inside the crate so a new variant is a compile error until it is pinned. Once #98 merges, a colliding append fails CI loudly instead of shipping a wire break.

Two other things worth knowing before rebasing, neither of them new to this PR but both easy to miss:

• This branch currently reverts four fixes merged to main since July, so the rebase is real work rather than a fast-forward.
• It is versioned for a release slot that no longer exists. The PR says it bumps 0.8.2 to 0.8.3; crates.io is at 0.8.5, and main is at an unpublished 0.9.0 which already carries a breaking change (the fix(security)!: remove RegisterDelegateWithPredecessors wire variant (0.9.0) #91 RegisterDelegateWithPredecessors removal). feat(delegate): unsubscribe, subscription introspection, and pin every wire tag #98 is going out as part of that 0.9.0 release.

Nothing here is a judgment on the wakeup design itself, which is unchanged and still wanted — freenet-core#5467 Phase 2 tracks it, and notes that the host half (freenet-core#4666, branch feat/3972-delegate-wakeup @ 9139913c) was written and Full-tier reviewed before being closed unmerged for want of a live consumer.

[AI-assisted - Claude]

[sanity]

Recording a tag decision here so it does not live only in a working session, since whoever rebases this will not have seen it.

Ian ruled that unsubscribe takes tag 8; this PR moves to tag 9.

freenet-stdlib#98 appends UnsubscribeContractRequest to OutboundDelegateMsg and UnsubscribeContractResponse to InboundDelegateMsg, both at tag 8. So ScheduleWakeup and WakeupFired become tag 9 in their respective enums, and this PR's two wire-format pin tests need their expected tags updated from 8 to 9.

Both enums are bincode-encoded with the variant index in declaration order, so two independent "append at the end" branches silently renumber each other. That is now a loud failure rather than a silent one: #98 adds a per-variant tag pin whose map is an exhaustive match inside the defining crate, so appending a variant without pinning it is a compile error, and a probe asserts the next tag along does not decode so the variant counts cannot drift. Rebasing onto it will tell you immediately if a tag collides.

Two other things worth knowing before picking this up, neither a criticism of the change itself:

1. This branch currently reverts four fixes merged to main since July, including the fixed_size_field decode-panic hardening and the unknown_union_discriminant change in delegate_interface.rs. That is branch staleness rather than intent, but a naive rebase would undo them.
2. The version target has moved on twice. The description says it bumps 0.8.2 to 0.8.3; 0.8.5 is published and main is already at an unreleased 0.9.0 carrying a breaking change (fix(security)!: remove RegisterDelegateWithPredecessors wire variant (0.9.0) #91).

[AI-assisted - Claude]