Understanding Salt Generation for Password Hashing
Entropy is a measure of the number of possible outcomes for the whole system. If you start with three random bytes, then there are 16777216 possible inputs. Regardless of what you do from these inputs, you will only get 16777216 possible outputs; no amount of hashing & cutting & praying will change anything to that — except possibly by reducing the number of possible outputs. With your hashing and then truncation to 3 final bytes, there is no guarantee that all 16777216 values for these three bytes will be possible. In fact, you should get about 10 millions of them, no more.
A salt is only as good as it is unique. It does not need to be secret or unpredictable, but you should strive for never using the same salt value twice, or at least to keep the reuse to the bare minimum. If your salts must fit in three bytes, and your source of randomness is three bytes, then the best you can do is to simply use these three random bytes as salt. Hashing them is just a needless complication, which has no security benefit, and actually reduces the space of possible salt values, thus implying a higher reuse rate.
You could generate salts with a non-random process, if you can keep a state. Namely, maintain a counter, which is incremented for every generated salt. Counter management can be troublesome (especially in multi-frontend systems), which is why using randomness is often preferred. But that randomness is just a tool to achieve uniqueness. It is not a problem if salts are not random or follow a predictable sequence. The problem is when you reuse a salt value.