sled expungement should clean up sled underlay allocations

Right now, if you add a sled and then remove it, I think we'll wind up leaking the sled_underlay_subnet_allocation row for it. There are only about (255 - 33) = 222 possible records in this table per rack, so I expect this means that we'd be unable to add more than 222 sleds to a rack (no matter how many expungements have been done).

We probably don't want to remove (or invalidate) these records until the sled actually becomes decommissioned. Otherwise, we might pick the same subnet for a newly added sled and there may be components on two sleds using the same subnet. Separately, we might want to avoid reusing recently-used subnets anyway.

Trace the sled expungement path and its handling of sled_underlay_subnet_allocation; confirm when a sled becomes decommissioned and how allocation rows are retained or released. Done means expungement no longer leaves unreclaimable rows while avoiding subnet reuse before decommissioning, with coverage for both cases.