Three issues fixed:
1. Start/stop returned 404 for forwards owned by other nodes:
findLinkByTriple only checked local SQLite store. Added
findLinkFromTopology fallback — startForward/stopForward now look up
ring topology entries when the local store doesn't have the link.
2. Group labels didn't sync through the ring:
handleForwardsAssign only updated local SQLite, never the ring
topology. Added State.UpdateTopologyGroup + Engine.UpdateTopologyGroup
— handleForwardsAssign now updates both. Added topologySync callback
called after every e.state = tk.State (OnToken) and e.state = s
(AdoptState) to re-apply local store group overrides onto the freshly
adopted topology, so they survive state adoption and propagate via
the next token forward. handleForwardsGroupDelete also clears ring
topology entries.
3. Status-merge branch omitted Group field:
ring-only forwards always showed '未分组'. Added Group: t.Link.Group
to the topology-merge forwardStatus.
Verified: 4-node cluster, 5 forwards, group assigned on node-a
propagates to all nodes within one token cycle; stop from non-owning
node succeeds (HTTP 200) and worker stops on the owning node.
Root cause: handleStatus built forwards only from local SQLite links table;
handleCanvasGet returned only local store data. Neither merged the ring
topology (which IS synced to every node in-memory). Result: non-claiming
nodes saw only their own claimed forwards, not the full cluster.
Fix: read-time merge in both handlers — iterate ring topology entries and
add any (local, remote, link) not already in the local store. No store
writes (avoids the per-forward stop/start issue that broke the old
topology-derived-canvas model).
Verified: all 4 cluster nodes now show 5 forwards / 4 remotes / 5 links;
isolated node-e correctly shows empty.
