Whenever you do the inverse DCT transform to get back to the image you are going to have a floating point result. That is unavoidable. Assuming the image format you are using requires integer values (not an image guy, so I'm not sure if there are any formats that allow floating point values- probably not) then rounding is unavoidable. Rounding means losing information, which means that it is impossible to avoid the possibility of the DCT LSBs being affected, using the method that you describe.
You could recover meaningful information by making larger changes in the DCT values, but that also means that the change to the image would be greater. You could perhaps recover useful information through the use of forward error correction (FEC) codes, but you would need to have a better understanding of the error characteristics before you could answer that.
EDIT: I did a little research on JPEG and JSTEG and I think (though I could be mistaken) that you misunderstand what is going on. JSTEG works on JPEG files. In order to do its compression, JPEG encoders DCT transform the image (starting with the luminance/chroma model, rather than RGB) and keep all the luminance information while essentially tossing all but the low-frequency chroma information. This works as compression because the file stores the DCT values, not the direct image values (it's a little more complex than that, but close enough to the truth for this discussion). Thus, the fact that the inverse transform wipes out your LSBs doesn't matter. In fact, it is probably a plus. For the purposes of steganography, you get the steganography bits from the file itself, not the decoded image. Thus, the recipient of the hidden bits has access to the DCT values with their LSB payload.