Bound provider UID metadata to preserve SWIM state broadcasts #468

Summary

Provider state broadcasts attach dynamic-provider UID metadata before SWIM byte-budget fitting. The current fitter trims MCP tool catalogs but never trims UID metadata. If UIDs push an otherwise-fitting inference snapshot over the configured application payload budget, the fitter can leave the broadcast oversized and SwimNode::publish_state_broadcast rejects the entire snapshot. Peers then miss provider updates, including updates for static providers.

This is a focused follow-up to the broader oversized-broadcast work in #177.

Requested change

Make provider UID metadata fit within the remaining SWIM broadcast budget without allowing that metadata to block an otherwise-fitting provider snapshot. Use a deterministic policy to retain only the UID records that fit, or omit UID metadata when there is no room. The core provider snapshot should still be queued whenever it fits without the UID extension.

When a UID is omitted, peers may defer accepting discovered inventory for that provider until a later UID advertisement. That delay must not prevent propagation of the provider's ordinary CRDT state.

Acceptance criteria

• UID metadata is included in the encoded-size calculation used for provider-state budget fitting.
• If the provider snapshot fits without UIDs but not with all offered UIDs, a bounded broadcast is still queued with the provider snapshot intact.
• UID selection or omission is deterministic across reconciliations.
• A near-budget regression test proves that UIDs cannot cause an otherwise-fitting provider update to be rejected.
• A no-room-for-UIDs test proves the provider update is still queued without UID metadata.
• Existing tool-catalog fitting continues to respect the same byte budget.

Scope note

If the inference/provider snapshot itself exceeds the budget without UID metadata, that remains part of the broader #177 work; this issue covers UID metadata as the incremental source of overflow.