docs: correct doc comments that describe behaviour the code does not have

[0xrlawrence]

Four comments that a reader would reasonably act on, each contradicted by the code immediately below it. Comments only, no executable code, signature, or type is changed.

1. pallet-validator-set documents a bond it never takes

Three places refer to one: the module header attributes spam resistance partly to it, ApprovedValidators says approval happens "after bond", and PendingValidators describes its entries as having a "bond locked".

register_validator locks nothing, and the pallet's Config has no currency dependency at all, so there is nothing to lock with. The queue is bounded by MaxPendingValidators and the two prerequisites, and it is worth noting explicitly that register_relayer is itself ManageOrigin-gated, which makes the relayer prerequisite a considerably stronger gate than the header implies. Someone reading the current text could reasonably conclude there is economic skin in the game here.

2. The unshield change-memo comment is 4 bytes out of date

It lists the plaintext as [value_lo(8), value_hi(8), owner_pk(32), blinding(32), asset_id(4), counterparty_pk(32)], which is 116 bytes. MemoData has been 120 since circuit_version was appended.

This one has teeth: a client written against the comment produces a memo the pallet accepts (is_valid_size() only checks non-empty on this path) and that no wallet can decrypt, so the change note is silently unrecoverable. Corrected, and added the 180-byte wire format since that is the number a client actually needs.

3. The event split does not prevent graph correlation

NullifiersSpent and CommitmentsInserted each say they are "emitted independently ... to prevent graph correlation". Both are deposited by the same extrinsic and therefore carry the same Phase::ApplyExtrinsic index, so joining them is a one-line indexer query.

The split is still worth keeping, and the actual unlinkability is real, it just comes from the commitments and nullifiers being opaque rather than from the events being separate. Reworded so the comment does not claim a property the runtime cannot provide, since a privacy claim in a doc comment tends to get repeated downstream.

4. The mainnet genesis preset is an unmarked placeholder

mainnet() passes an all-zero sudo key, empty validator and session-key lists, and no verification keys. Nothing in the file says it is a placeholder, and it sits next to development() and testnet(), which are real.

Each of the three is independently fatal: nobody holds the secret for the zero account, so there is no governance origin and no way to register verification keys; the empty validator list means pallet-session hands Aura an empty authority set and no block is ever produced; and with no VKs every shielded operation fails regardless. Added a doc comment saying so rather than changing the values, since I do not know what they should be.

Verification

I was not able to build the workspace, so I have not run cargo check or cargo fmt --check against this. The changes are all inside // and /// comments with hard-tab indentation matching the surrounding code, so I would expect both to pass, but please treat that as unverified.

---

Separately, I have emailed security@orbinum.net about a small number of higher-severity findings from the same review pass. Those are deliberately not in this PR, in any other PR, or in a public issue. Happy to hold them for as long as you need.