Still makes me wonder why the last pixels are clipped. I've been under the assumption that no matter what size the sprite/texture is it's dimensions are always stretched to the power of two in the GPU memory.
Maybe some engines do this, but Construct does not, it places the texture unscaled with transparent edges on the smallest power-of-two texture that can accomodate it.
You could also get into the habit of using .dds files
Construct does not use DDS internally, so the file format you use won't affect this.
As for your original problem, the technical reason the clipping of 1 pixel occurs is this:
Construct supports scrolling to floating-point co-ordinates (this will happen centering the window on almost any moving sprite) for optimal display. It makes scrolling and motion very smooth. However, it causes a problem for tiling.
Graphics cards can natively tile any power-of-two texture seamlessly, a bit like using a mesh distort on a sprite with UV co-ordinates above 1. The problem is when the texture is not power-of-two, Construct stores it on a power-of-two texture with transparent edges, so tiling that would have transparent areas between each tile - not very useful.
So in that mode, Tiled Background resorts to an alternative tiling system which basically amounts to drawing separate sprites in a grid. However, when you scroll to a floating-point co-ordinate, you end up drawing these tiles at floating-point offsets, which overlap, but due to the way they blend, they have one pixel seams between them. There were a lot of complaints about the seaming - it doesn't look good at all. So as a fix, pretty much the only thing that I could do was move the tiling back one pixel, so the next tile covers up the seam. But you lose one pixel to the bottom and to the right of your tile. As far as I remember, if you stretch up an image to fill the power-of-two texture and tile that, it blurs the actual texture, so isn't any good either. Basically, there's no way to perfectly tile non power-of-two textures with floating point scrolling.
Note the layout editor does not support floating-point scrolling, so you always see it perfectly here. (it should probably preview the same as it'll appear in the runtime though, I guess that's a bug)
The only way around it is to use power-of-two textures. I can't even make it tile perfectly if you disable floating point scrolling by forcing scrolling to round(x) and round(y) - then applications which do scroll smoothly will see their tiles jittering by one pixel when it hits an integer scroll position.
So yeah, it's complicated. But basically you can totally side-step all the problems, just by using a power-of-two texture, as is documented (although maybe the object itself should tell you). Those tile perfectly on the GPU. So, there's your explanation, and your fix