DPL: give each stream its own slot in the service registry - #15680

The registry derives a service's slot from the low 8 bits of
type.hash ^ valueFromSalt(salt), but valueFromSalt puts streamId at bit 16, so
streamId contributes nothing to it: every stream lands on the same slot for a
given service, they pile into one MAX_DISTANCE-deep probe window, and the first
which does not fit is refused -- with the error naming whichever service lost
the race rather than the one which filled the window. Mix the salt into the low
bits instead: only the starting slot changes, since valueFromSalt still carries
key equality and both getPos and registerService go through
instanceFromTypeSalt, and unlike widening the table this raises no new ceiling,
the mask staying below bit 16 until MAX_SERVICES passes 65536. The added test
registers one instance of the same stream service for each of 32 streams and
asks for each of them back; on the old slot calculation it gets seven in before
registration is refused.