END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

Code, need code to test, if your fragments compile with warnings fix them first, there are all kinds of things that can contribute to the problem so eliminate the narrowing, implicit cast and may be used uninitialized warnings, that is where I would start when you are sure that the problem is not with the fragment code then it will be easier to track down.
As this is the first I've heard of this and the texture stuff in the latest version is (essentially) the same as github Fragmentarium-master I would be asking myself "when did this start and what changed at that time".

The default "internal GL Magic" for textures is...
...which is always used for rendering the fragment generated image with the buffershader

to change the default behaviour you can add #TexParameter textureName param option
valid params GL_TEXTURE_WRAP_S GL_TEXTURE_WRAP_T GL_TEXTURE_MIN_FILTER GL_TEXTURE_MAG_FILTER
valid options  GL_CLAMP GL_REPEAT GL_NEAREST GL_LINEAR

the mipmap option works like this...

parameters and options set this way will be applied to the named texture whenever it is used, this is about all I can tell you about the internal texture stuff, I'm not a GL guru, still learning, enlightenment is always welcomed.

Here's the file of how it looks.
Note the ground which is IBL-lit.
Same happens for tiling imperfection on the sky map.
The seam itself may be a result of some rounding, but the fact its so pixellated points to the same issue.

mipmap is disabled by default internally (C++ side, that's why you need to explicitly use #TexParameter to turn it on)

To disable (this should not be needed!!!)...
...when this is the only parameter set on a texture mipmap is disabled in GL

as Syntopia states "Some GLSL operations operate on 2x2 screen space pixel blocks. " so...
used in assorted buffershaders, these read the rendered image texture for post processing and final display, afaik these act on the entire image not just one texture in part of the image.

if the effect is only on the edge and not across the entire bg-map then double check your bg-map, then double check your code for an off by 1 err on the x axis?, textures also work "nicer" if they are square and size is  2^n, of course without code and data we can only guess at what the problem might be...

edit: is this a Synthclipse problem or a Fragmentarium problem?

did you alter the value in the rand() function from 43758.5453 to 3758.5453 to fix banding in IQ-Clouds 
this may affect dither in places

yeah, that's probably the wrong thing to do,
replace only the one that IQ-Clouds uses as this seems to fix banding artefacts,
then,
replace another one and TEST!,
then,
replace another one and TEST! etc...
being mindful of what parts of the render these should affect, until you find the places where this works for removing banding artefacts.

and read https://www.opengl.org/discussion_boards/showthread.php/176425-How-are-dFdx-and-dFdy-functions-implemented for some insight on how the dFd functions work.

so, to recap...
the tiling seam imperfection on the sky map is not a Fragmentarium problem because it renders correctly in Fragmentarium.
the pixelation problem, also not a Fragmentarium problem but was caused by your global changes to the rand() function.

Aside: that rand() function is a terrible hack to begin with, and the hacked version is even more dubious with the the lower frequency. If you think about what a random number function does / what you want from it, this function can never work properly...

A basic random number gen can be done in little state with eg xorshift.