fix: keep a long line of code from widening the editor page

[TallblokeUK]

Fixes #518.

A single long unbroken line of code widened the whole editor page, pushing the Save Snippet sidebar outside the viewport and leaving the document scrolling sideways. Line wrapping being enabled made no difference.

.snippet-form laid its content column out as a bare 1fr, whose automatic minimum is the column's content width, so the track grew to fit the line's intrinsic width and took the sidebar with it. The column is now minmax(0, 1fr), and the two content areas within it no longer take their content width as a minimum either.

Verification

• New end-to-end test loads a snippet with a 4,000 character unbroken line and asserts the document does not scroll sideways and the sidebar stays on screen, with a documented one pixel tolerance for sub-pixel rounding.
• Without the change that test reports 32,943 pixels of horizontal overflow; with it, zero.
• lint:styles and lint:js pass.

[TallblokeUK]

Superseded. The conclusion below was wrong: the failure was caused by the test in this pull request. See the correction further down.

---

The file-based execution job is red here, and the evidence says it is not this change.

Check	Result
Locally, same project, with this change	5 of 5 pass
CI, first attempt	3 tests failed
CI, re-run	8 tests failed — a different set
Default Playwright project, same specs, same commit	pass
Same job on #572, #573, #575 and #576, all off this base	pass

The failure count changes between attempts on identical code, so it is not deterministic. A stylesheet change cannot vary its effect that way, and it cannot decide whether a PHP snippet executes at all.

Every failure is in code-snippets-evaluation.spec.ts, which is the one spec that depends on snippets running from flat files. The default project runs the same spec against the database and passes it.

That points at the flat-file execution path rather than anything here, which is the subject of #561. Worth re-running this job once that fix has landed.

[TallblokeUK]

Correction to my earlier comment: the red file-based job was caused by this pull request. Not by the stylesheet change, but by the test added alongside it.

That test created its snippet through WP-CLI. In CI, WP-CLI runs as root inside the container, and with file-based execution on, a snippet saved that way was the first thing written to the flat-file directory in the run. The directories were therefore created owned by root, the web server could not write snippet files into them afterwards, and every snippet saved through the editor from then on never reached disk. code-snippets-evaluation.spec.ts runs next and is the only spec that checks a snippet actually executes, which is why it was the one that failed.

It did not reproduce locally because wp-env maps the web server to the same user as WP-CLI, so the two can never disagree about ownership there. Running the suite the way CI does, against a flat-file directory nothing had yet been written to, reproduced the same two assertion failures with the directories owned by uid 0.

The test now saves its snippet through the editor, as the tests around it do. Under the same reproduction it passes, the directories are owned by the web server, and the evaluation tests pass. It still fails without the stylesheet change, reporting 32,918 pixels of horizontal overflow.

Worth knowing beyond this pull request: any end-to-end test that saves a snippet through WP-CLI before a file-based run has written anything will do the same, and nothing reports the failed write.