Welcome, AxiomVerge!
It is a bit tricky to get the exact effect you would like. Rendering to a buffer and drawing that at 4x isn't enough
that would be equivalent to just zooming in with the mouse wheel
we also need to round attachment positions to the nearest pixel (as you mentioned). Rounding attachment vertices doesn't work well if we allow non-integer positions in the setup pose. Rather than trying to keep all bones and attachments on integer positions, maybe it's sufficient to only round how much an animation affects positions. Eg, modify TranslateTimeline apply so bone position modifications are always full pixel amounts:
bone.x = bone.data.x + x * alpha;
Becomes:
bone.x = bone.data.x + Math.round(x * alpha);
The effect is really only useful for translation, since the skeleton's world axes can match the screen axes, we can map texels to pixels 1:1. That's no longer the case for most rotation and scale, so filtering has to be applied. Interpolation between rotation and scale values is smooth and may ruin the pixel art effect. Use of rotation is very common with skeletal animation, it would be difficult to avoid.
Putting a branch in the already CPU intense TranslateTimeline apply to make rounding optional isn't great. We could support the visualization only in the editor, but one of our goals is to render at runtime exactly as it does in the editor. For now I would suggest making the change in your copy of the runtimes. If you are using the official runtimes I expect you'll need a change like this to get the pixel effect with your game toolkit.
I'm sure you are still interested in what can be done in the editor so you can see there what you'll see at runtime. I know you used the 1px movement as an example, but FWIW, for that particular use case you could use stepped interpolation for a 1px translate key so the editor behavior matches your runtime. At low resolution it might be feasible to use a number of stepped translation keys. If you never pose your animations between frames at runtime, then you can set a key every frame and won't have the unwanted interpolation. I know this is not ideal, but may be an acceptable workaround. The main drawback is that editing an animation later can be difficult when there are many keys. You can lower the dopesheet framerate to reduce the number of keys, if you find that acceptable for your animations. Key adjust may help a little too.
