docs: state the contract conformance requirements authors must meet

[sanity]

Problem

The merge laws are in the whitepaper, but not in the API docs the person writing a contract actually reads. An author can implement update_state as last-write-wins today without ever being told that is wrong, and deployed contracts have done exactly that: freenet/freenet-core#5153 measured last-write-wins merges and mutual rejection accounting for a large share of all update work on the network.

Approach

Documentation only. No code changes.

Two earlier PRs already covered part of this ground (#92, idempotent and associative merge; #90, the delta-size requirement), so this fills the remaining gaps rather than restating them:

• Canonical byte representation. Every valid logical state must have exactly one encoding. The platform compares states by bytes and has no way to know that two encodings mean the same thing, so it treats them as still-diverged and keeps trying to reconcile. Includes the practical advice an author needs: sort map and set entries, fix field order, avoid formats whose iteration order is not deterministic.

• Merging is update_state. This is the framing that makes the failure mode legible. Returning the current state unchanged asserts merge(A, B) == A; if the peer holding B runs the same contract and does the same in reverse, the two results disagree, the peers never converge, and every future sync retries forever. It is easy to write that as a reasonable-looking "reject stale updates" check, which is exactly why it needs saying out loud.

• summarize_state determinism, with the reason: peers compare summaries to decide whether they have converged, so a summary that varies with hash iteration order makes two peers holding identical state look permanently divergent (State updates permanently lost for rarely-changing fields: silent ContractQueueFull drop + sender-side neighbor-summary poisoning freenet-core#4857).

• get_state_delta determinism, plus the explicit note that deltas do not need a single global canonical encoding, unlike state. Two peers reconciling from different starting points may legitimately produce different delta bytes, and delta correctness is judged by applying them and comparing the resulting canonical states.

• Emitted states must be valid, and states declared Valid must already be canonical.

What is deliberately unchanged

The existing warnings that noncompliant behaviour may get a contract deprioritized or removed from the network.

An earlier draft of this PR softened them, reasoning that no such enforcement ships today. That is accurate, but removing a deterrent the project deliberately published is a policy decision rather than a documentation fix, and the direction of freenet/freenet-core#5320 is to make those sentences true. Softening now and re-hardening later would be churn.

Testing

cargo doc --no-deps -p freenet-stdlib builds. The 4 warnings it emits are pre-existing and all in files this PR does not touch (state.rs, update.rs, client_events.rs); the changed file produces none.

Refs freenet/freenet-core#5320

[AI-assisted - Claude]