The sprint goal is typically a short missive you can communicate in business terms. For instance,
We want to deliver the customer profile page
If that takes 1 day or 2 weeks, mission accomplished. In fact, as a business, you would rather have it in one day than two weeks, wouldn't you?
The artifact of people must appear busy comes from an idea that time spent working is valuable, as opposed to its outcomes. The business is paying for these people whether or not the business goal is met, so let's try to get as much out of them as possible, is the the thinking.
A corollary to that equating time with value is that the stuff that is needed to keep the lights on, or to make delivering the next business goal easier, isn't valued as much.
The people who build and collaborate to create software are humans, and therefore software itself takes on the same level (if not more) of complexity as the humans that created it. That complexity needs to be pruned, managed, and kept at bay. We sometimes call this "refactoring", and sometimes we call it "maintenance", but we should probably be more precise in our terminology. Sometimes it's scaffolding (akin to the scaffolding used to build buildings but that disappears after the building is built), sometimes it's adapting to changes in the environment; and sometimes it's reacting to changes by external actors.
Software is not a closed system, and so it is affected by everything it touches or that touches it.
I say all this to say that the slack time afforded by a sprint whose goal was completed early is a blessing for you and your team. Use this time to scaffold, or adapt to environmental change, or react to changes by external actors (like making your build system more resilient to NPM outages if you run a node.js stack, for instance), or to refactor or improve the maintainability of your system.
These are all unseen and yet critically important activities that more businesses and teams need to devote time to to ensure their business goals can be met in a timely manner.