1) To shorten the UUID, you can simply XOR the top half with the bottom (and repeat until it’s short enough for you). This will preserve the distribution characteristics. Like any solution that shortens the output, it will increase the possibility of collision due to the birthday paradox
2) XOR amounts to a trivial hash, but since no additional mixing is needed, it’s fine. You could use a CRC or noncryptographic hash on your UUID, but I don’t believe it’s any improvement.
3) If you’re willing to accept some central management, it doesn’t have to be painful. A central authority can dole out medium-sized blocks of address space to each client, then the client can iterate through that subrange when assigning ID’s. This guarantees that there are no collisions, but also avoids a round-trip for each ID. One way to do it would be to use a 32-bit integer for the ID, doling out a 16-bit block at a time. In other words, the first client gets handed 0001, which allows 00010000 to 0001FFFF.
4) You could insert into the database with a UUID, but also have an identity field. This would provide an alternate, more compact unique ID, which can be limited to a 32-bit int.