fix: close #199 — remove Jaws.Replace and reject Replace/Remove broadcasts

[linkdata]

What

Closes the #199 DOM/server identity desync at the source, in two commits:

1. Remove the Jaws.Replace(target, html) convenience helper and its two test callers.
2. Reject what.Replace and what.Remove in Jaws.Broadcast — the public broadcast entry point — reporting the new sentinels ErrReplaceNotBroadcastable / ErrRemoveNotBroadcastable via reportMisuse and sending nothing.

Why

Jaws.Broadcast is public and handleBroadcast forwards unrecognized commands verbatim to every matching element. So removing the Jaws.Replace helper alone was not enough — a caller could still send wire.Message{What: what.Replace, ...} (or what.Remove) through raw Broadcast and reproduce the same strand: the DOM node is mutated/removed while the server-side Element stays registered with no reachable DOM node.

Both commands mutate a specific element's node in a way a broadcast cannot keep in sync with the server-side registry:

• Replace swaps the whole node for HTML that must carry the element's own id; one broadcast payload cannot preserve the distinct id of every matched element.
• Remove deletes a child node and requires the child's Element to be unregistered server-side. The broadcast default path never calls DeleteElement, and the client acks only the child's descendants, never the child itself (jawsRemoving uses querySelectorAll, which excludes the node being removed) — so the child Element is stranded. This is precisely why the safe per-element Element.Remove calls Request.DeleteElement(child) itself.

Safe forms (unaffected)

• Element.Replace — per-element, validates the replacement carries the element's id.
• Element.Remove — per-element child removal, unregisters the child server-side.
• Jaws.Delete — broadcast-level element removal that stays in sync (its handleBroadcast case calls DeleteElement).
• The what.Replace / what.Remove wire commands and all client-side handling are untouched.

Breaking change

Removes the exported Jaws.Replace method (API break for any external caller; nothing in-repo used it outside tests). Jaws.Broadcast now rejects what.Replace / what.Remove messages instead of forwarding them — these were never emitted by any in-repo helper.

Verification

• go build ./..., go vet ./... — clean
• go test -race ./... — all packages pass
• gofumpt (touched files), staticcheck ./..., golangci-lint run ./... — clean / 0 issues
• TestBroadcast_RejectsElementMutatingCommands — table-driven regression test exercising raw Jaws.Broadcast for both Replace and Remove, asserting the sentinel is reported and nothing reaches bcastCh (covers both the debug-panic and production-log branches).

Noted, deliberately out of scope

• Broadcasting what.SAttr/what.RAttr with id is refused only client-side on the raw-broadcast path (the server-side ErrReservedAttribute guard lives in the attribute helpers). This does not strand — the id-bearing node survives — so it is not a Jaws.Replace leaves live server Elements without a DOM identity #199-class defect. Happy to follow up separately if you want the server-side guard extended to the broadcast path.