PIP-50: align the spec with the reference implementation

[carbonflake]

Summary

This revises my Draft of PIP-50 after writing a full implementation in the node
(branch pip-50-state-anchor
of CarbonFlake256x/pactus). Building and testing it, and two external reviews, showed where
the spec was ambiguous, inaccurate or unsafe. The intent is unchanged: one live,
deposit-backed commitment slot per account.

Status stays Draft. The node pull request will stay a draft until this PIP is Accepted.

What changed vs the merged revision

Topic	Before	After
UpdatedAt*	Refreshed by every Set	Moves only when RootHash changes: a top-up, a new ManifestURI or a new AnchorType keeps the attestation date
Replay	"A replayed Delete may remove a re-created slot"	Corrected: an executed transaction can never run again (the ID cache covers the whole lock-time window); only the order of pending transactions remains, as for every type
Delete	Implied revocation	Stated: not a dated revocation; to revoke durably, keep the slot and publish a revocation root
Delete arithmetic	Balance + locked - fee unchecked	Explicit PIP-54 overflow check
MinAnchorDeposit	"Reuses MinimumStake"	Initial value, priced per byte of state like a validator record; bounds anchor state by supply; changed by a later PIP
Tx pool	"Sized like Transfer", MUST	10% of MaxSize (SHOULD, local policy); MaxSize is the unit of per-pool caps, total 1.1 × MaxSize; anchors placed last in blocks
JSON bytes	hex in JSON-RPC	base64, like every protobuf bytes field; integer encodings and a BigInt note for locked_deposit
ZMQ anchor_info	Height little-endian	Big-endian like every other topic; exact frame layout and sequence gap rule
GetAnchor	Unspecified for validator/treasury	found = false; only a malformed address is an error
ListAnchors	Scan of all accounts	In-memory index rebuilt at startup, no extra pass over the store, 28 bytes per anchor
Remote nodes	Implicit	GetAnchor from a third-party node is not trustless
Activation	75% implied as a validation rule	Clarified as the PIP-51 proposer rule, and why validation cannot enforce it
PAC-ANCHOR-1	simplemerkle (duplicates the last node, no leaf/node separation)	RFC 9162 tree with BLAKE2b-256, name-bound leaves, size-bound root, strict manifest rules, JSON proof document, test vectors
Size bound	"< 2 kB × N_accounts"	220 bytes per anchor everywhere
Tests	26 cases	Tests 21 and 22 updated, test 27 (replay after re-create) added

The PAC-ANCHOR-1 change matters most for applications: with the Bitcoin-style tree,
[a,b,c] and [a,b,c,c] share a root, and an inner node can be proven as a 64-byte file.

Implementation status

The reference implementation covers the whole spec: payload, execution, pool,
activation at protocol version 5, gRPC / JSON-RPC / HTTP / ZMQ, wallet, and a
util/anchorprofile package for PAC-ANCHOR-1. Tests include lifecycle, two-node
consensus, restarts, fuzzing, a replay-window test on a real store and an end-to-end
run on four nodes.

PR Checklist

• I have read and followed the proposal guidelines in PIP-1.
• This replaces PIPs/pip-50.md in place (same number, same author).