Timebox it to the stated time, and then write down what you did not do. That last part is the whole technique and it changes the outcome.
What I submit:
Working code for the core requirement, done properly rather than broadly. Better to have one path that is clean, tested and thought about than five features half done.
A readme with a section headed what I would do with more time. List the edge cases you spotted and did not handle, the tests you would add, the thing you would refactor, the trade-off you made and why.
That section does more work than the code. It demonstrates that you saw the same things a longer submission would have covered, that you can prioritise under a constraint, and that you can communicate about your own work - which is most of what a reviewer is actually assessing.
Say how long you spent, honestly, in one line at the top.
What this also does is protect you from the version where you spend twelve hours and it is still not enough, because there is always more. A take-home has no natural end and the person setting it often has not done it themselves recently.
And a reviewer who penalises an honest four-hour submission against a stated four-hour brief has told you something useful about the place.