serviceability-instruction: device domain builders (RFC-26 R1)

[juan-malbeclabs]

Summary

RFC-26 R1 (stacked on the previous phase's branch). Complete the device domain on top of the R0 exemplars: update_device (max(old,new) dz_prefix block), set_device_health, and interface create/delete/update (Vpnv4 topology PDAs, segment-routing reconcile).

All builders route through authorize() -> build_with_permission unless noted; each carries a verbatim account-layout doc-comment copied from its processor.

Testing Verification

• Unit tests assert the exact AccountMeta list (incl. trailing [payer, system]) and the borsh tag byte for every builder, covering the conditional/variable-account paths.

Closes #4016. Part of RFC-26 (rfcs/rfc26-rust-instruction-builder-library.md).

---

PR stack (RFC-26 builder library)

Stacked PRs, merge in order (each is based on the previous one's branch):

1. serviceability-instruction: scaffold pure instruction-builder crate (RFC-26 R0) #4049 — R0 scaffold + exemplars
2. serviceability-instruction: device domain builders (RFC-26 R1) #4050 — R1 device ← this PR
3. serviceability-instruction: link domain builders (RFC-26 R2) #4051 — R2 link
4. serviceability-instruction: user domain builders (RFC-26 R3) #4052 — R3 user
5. serviceability-instruction: location/exchange/contributor builders (RFC-26 R4) #4053 — R4 location/exchange/contributor
6. serviceability-instruction: multicastgroup + allowlist builders (RFC-26 R5) #4054 — R5 multicastgroup + allowlists
7. serviceability-instruction: tenant + permission builders (RFC-26 R6) #4055 — R6 tenant + permission
8. serviceability-instruction: topology + feed builders (RFC-26 R7) #4056 — R7 topology + feed
9. serviceability-instruction: accesspass + resource builders (RFC-26 R8) #4057 — R8 accesspass + resource
10. serviceability-instruction: globalstate/globalconfig/allowlist/index/migrate builders (RFC-26 R9) #4058 — R9 globalstate/config/allowlist/index/migrate

R10 (commands/* migration + program-test) and RF (fixtures) follow as separate PRs.

[nikw9944]

RFC-26 R1 device builders (RFC). Account order, writable/readonly flags, conditional-account logic, and variant tags (23/83/73/74/76) verified line-by-line against all five processors and the existing SDK commands — they match for valid inputs, and a mis-stated old_dz_prefix_count can only fail the transaction, never corrupt state. All 16 crate tests pass; clippy and fmt clean. The dz-ledger-program-review checklist pass found the on-chain-only classes correctly untouched (no AUTHORIZE_GATED_FLAGS / resource verify changes needed).

One High finding: create_device_interface/delete_device_interface leave use_onchain_allocation/use_onchain_deallocation caller-controlled (default false), which the processors reject unconditionally — the SDK forces true, and the builders should too (they already own topology_count). Medium: the release-mode u8 clamp (debug_assert! + unwrap_or(u8::MAX)) can emit a topology_count that disagrees with the account list, contradicting the R0 siblings' explicit panic-on-overflow policy in the same file; old_dz_prefix_count should be coupled to the dz_prefixes it qualifies; and the tri-state's Some(&[]) clear-topologies case is untested. Lows are hardening/doc/test-coverage items, including full-struct PartialEq asserts per the repo's testing standard.

• Medium (test gap): update_device_interface's tri-state middle value Some(&[]) (clear all topologies) is untested — the one combination exercising the processor's presence heuristic with update_topologies=true, topology_count=0, seg-ext appended, zero topology accounts. Add test_update_device_interface_empty_topologies_clears asserting [device, contributor, globalstate, sri, payer, system], update_topologies == true, topology_count == 0.
• Low (awareness only): contributor/globalstate/globalconfig are sent writable although the processors only read them — deliberate byte-parity with the SDK per common.rs; downgrade to new_readonly when the fixture-parity constraint is lifted.
• Low (test gap): update_device resource-loop tests only cover old == new (1,1) and the no-prefix path; the max() asymmetry — shrink (old=3,new=1) and grow (old=1,new=3) — is untested, and shrink is the branch where the processor closes orphaned DzPrefixBlock accounts.