The maximum number of shares in Shamir's secret sharing is limited by the size of the underlying finite field. In particular, the maximum is one less than the number of elements in the field, since each share must be associated with a distinct element of the field, and one of the elements (usually the zero element) must be reserved for the secret being shared.
A quick Google search indicates that the com.codahale.shamir implementation always uses GF(256). Thus, it can support at most 255 shares.
If you switched to an implementation that used, say, GF(216), then the maximum number of shares would increase to 216 − 1 = 65,535. That should be enough for your purposes. If not, using GF(232) would let you have up to 232 − 1 = 4,294,967,295 possible shares.
The main disadvantage of using fields larger than GF(256) = GF(28) for Shamir's secret sharing is that you may need to pad your data up to a multiple of the field size. (With GF(256), the field elements are single bytes, so that's rarely an issue.) In your case, however, your secrets are always 32 bytes = 256 bits long, so you can safely use GF(216), GF(232), GF(264), GF(2128) or even GF(2256) without having to worry about that.