I would prefer the look-up table. In that way you can in the same operation adjust the output range to what you like.
As I said, there is no need to go deeper than 6 bits for black and white if you adjust 00 0000 to black, 1500 Hz and 11 1111 to white, 2300 Hz. See that undershoots and overshoots are clipped off. May be that you can allow some slight under- and overshoots. If the look-up table returns any way a byte, you may solve that in the table outputs. And who cares about the space of such a table, which resides in the progam space. You know how to do that?
In the past we did some experiments at Philips Research on the bit depth of video signals. The first thing that you see if you have too few bits is "contouring". You see then grey rings and areas in parts of the picture with almost equal grey level, e.g a back ground wall. This is no more visible if you have 64 shades of grey. But if you want to code the sync pulse in the digital stream you need 7 bits, because 44 shades is too few and contouring becomes visible. And if you want to digitize a composite PAL colour signal, you need 8 bits. This is also the reason that together with Vic we made the colour NBTV standard with 6 bits for Red and Blue and 6½ bits for Y, if I remember well.
May be that you can do the sync detection in the same way, may be it can be done in the same look-up table, in the two remaining bits. May be you get a slight jitter in the sync, but we can see if we can solve that further on in the chain. I think that a sync fly-wheel is any way a good idea. That will remove the jitter as well.