You can't solve the problem for 100 by using exactly the first two packets to communicate which bits are trustworthy and sending the rest of the message in the 16 trustworthy bits.

The solution for 100 does indeed communicate which positions are trustworthy and then sends the message on these positions, but it doesn't use exactly the first two packets. Instead, for each trusted position, on average 2 packets are used to communicate that. On some positions, already the second packet contains parts of the message, on some other positions, the message might only start in the fifteenth position.

Here's how you do it. A writes down all trusted positions $$$b_0, b_1, \ldots, b_{15}$$$ in sorted order. A then sends $$$b_1 - b_0$$$ zeros and 1 one on position $$$b_0$$$, $$$b_2 - b_1$$$ zeros and 1 one on position $$$b_1$$$, and so on, up to $$$b_0 - b_{15} + 31$$$ zeros and 1 one on position $$$b_{15}$$$. In other words, A notes down the (circular) distance between each trusted position and the next one, and then sends that many zeros and one one on that position.

You can show that no matter what C does, B can always uniquely decode the trusted positions from this data. In total, you use 31 bits on the trusted positions to do this, leaving you $$$66 \cdot 16 - 31 = 1025$$$ bits to transmit your message.

This almost works, but B doesn't know the length of the message and A doesn't communicate that. To solve this, pad your message to length 1025, using the opposite bit from the last bit of the actual message. For example, if the message ends with a 0, you add some 1-s to the end of the message so the length comes to 1025. That way, you know which bits to remove from the end to recover the original message.