glClear's result can't be seen when using bindless texture
This is clearly a bug in AMD's driver, though it's a very understandable one.

What is probably happening is that the driver does not correctly detect that there is a dependency between the framebuffer operation and the use of the texture. It's easy for an API to tell that you've bound a texture that was the subject of an outstanding render target command, since the API sees exactly what texture you're going to use. It can simply keep track of the texture objects recently used in an FBO, and if it sees you render with one of them bound, it issues whatever dependencies are needed to ensure that the operation is complete before the rendering operation.

It's much harder when you're not binding the texture; you're just passing an arbitrary number to the shader. The API has no idea if that number represents a render target.

To verify that this is the problem, insert a glFinish() between the clear command and the draw command that uses the texture. Odds are good that it will go away (or at least be partially mitigated). A glTextureBarrier() call might also fix it. If you're getting the texture handle after attaching the texture to the FBO, you might also want to get the handle first. Just in case that shakes something loose.

Note that you shouldn't have to do any of these; the specification requires that things work exactly as you expect.

What AMDs driver needs to do is to realize that you're using bindless texturing and emit the appropriate dependency operations when you change framebuffer render targets. That is, it has to assume that any glBindFramebuffer or any calls that modify the FBO that's currently bound will result in any subsequent rendering command reading from previously written textures. Therefore, it must issue a synchronization at the first rendering command that involves a bindless texture operation (if the texture used by the FBO is made resident).

Either that, or it somehow has to figure out which arbitrary integers represent which textures. This is very difficult, since you can pass those handles in a variety of ways. UBOs, for example; you don't want implementations combing through images.