4 bits per square has room in it for RLE flags and even counts, without increasing the worst case size.
But probably with encoding your solution would be better
1 bit for each square represent there is a piece on that pos so 64 bits
then for each side, 4 bits to represent number of pieces and 3 bits for each piece to represent their type
At max 64 + 2x(4 + 3 x 16)=168 bits for 16 pieces each side.
edit: nvm this wouldn't work since you wouldn't know the colors of the pieces on board. You need to store 4 bits for each piece, 1 color + 3 type so it is 64 + 2 * 4 * 16 = 196. I am not sure if this is better anymore
As far as max size goes, 64 bits plus data per piece seems to be the right path. Especially if you huffman the pawns to be 3 bits each while other pieces are 4 bits.
The grandparent method gets pretty bloated when you start promoting.
To beat it you must encode each piece with a different number of bits. E.g.
Q c00
N c01
P c10
B c110
R c1110
K c1111
The issue is that each time a P is promoted to R or B (a stupid thing to do, since a Q would be better) you need one or two bits more. On the other hand, you spare 3 to 5 bits for each captured piece. In normal play, captures outnumber promotions, and promotions are either to Q or N, never R or B, but theoretically...