Fleet identity and swarm registration for service data wrapped by a carrier #133

Problem

Some beacons put their own service UUID in the GAP service-UUID list, and put the actual service-data AD structure on a different 16-bit UUID that belongs to a carrier network. The carrier payload is often ephemeral (rotating identifier, authenticated or encrypted bytes).

FleetIdentity and SwarmRegistry only accept one bytes16 fleet UUID.

• SERVICE_DATA expands a single service UUID into that bytes16. It cannot also name the carrier UUID.
• The tag hash is keccak256(expanded service UUID ∥ service-data bytes). When those bytes rotate, a tag cannot be registered in an XOR filter. This is the same limitation already called out for ephemeral identifiers in the swarm spec.
• UUID_ONLY covers “every tag advertising this one UUID”. It cannot say “service data is the carrier, and the customer UUID is the one in the GAP list”. Registering the carrier UUID fleet-wide would include every customer of that carrier.

Ownership (claimUuid / uuidOwner) and swarm routing (registerSwarm → service provider) therefore cannot fully describe this beacon. A customer can own their service UUID, but the chain cannot say which carrier wraps it, or route only those wrapped advertisements to their swarm.

What we need

Extend fleet identity and swarm registration so a fleet can be defined on chain as:

• the customer service UUID (what is owned, and what an OS background scan filters on)
• an optional carrier service-data UUID (the AD 0x16 UUID that actually carries the payload)

With that pair, swarm registration should be able to:

• assign the fleet to a service provider (routing)
• use UUID_ONLY for the pair when the payload rotates
• keep per-tag XOR membership only when the identity inside the advertisement is stable

No change to the single-UUID cases (SERVICE_DATA with no carrier, iBeacon, Eddystone-UID, company id).