fix(feedback): Wrap long error messages in the feedback dialog

[Souptik96]

Closes #14930

Problem

.form__error-container declared only color and fill:

.form__error-container {
  color: var(--error-color);
  fill: var(--error-color);
}

With no wrapping or overflow handling, an error message containing a token wider than the container runs out of the dialog instead of breaking onto the next line.

Two things make that reachable rather than theoretical:

• The container sits inside .form__right, which is width: var(--form-width, 272px) whenever the screenshot editor is open (.dialog__position:has(.editor) .form__right). 272px is narrow.
• resolveFeedbackErrorMessage reads from the caller-supplied FeedbackErrorMessages option, so integrators can pass arbitrary error copy — including localized text with long compound words. Arbitrary-length, arbitrary-language strings are expected input here.

Both error slots in Form.tsx use the class (the submit error and the screenshot error), so one rule covers both.

Change

Adds a single declaration:

overflow-wrap: break-word;

break-word rather than anywhere on purpose: it breaks a word only when the word cannot fit on a line by itself, and it does not change the element's intrinsic min-content contribution, so no surrounding layout shifts. Normal whitespace wrapping is untouched.

This is the first wrapping declaration in the package — there was no existing convention in packages/feedback to follow (git grep for overflow-wrap|word-break|white-space in packages/feedback/src returns nothing), so I picked the least invasive standard property. Happy to switch to anywhere or add min-width: 0 if you'd rather be more aggressive.

Verification

packages/feedback, yarn test:

• Baseline on develop: 4 files / 24 tests pass.
• With this change: 5 files / 27 tests pass.
• Negative control — reverting only the CSS line and re-running: 1 failed / 26 passed, and the one failure is the wrapping assertion. The two sibling assertions (the --error-color tokens, and the nonce attribute) pass unpatched, so they are not coupled to the fix.
• oxlint . in packages/feedback: 0 warnings, 0 errors.
• oxfmt --check: the new test file is clean. I deliberately did not run oxfmt --write on Dialog.css.ts — it is already reported as unformatted on unmodified develop, and reformatting it would bury a one-line change in unrelated churn.

What I could not verify

jsdom does not do layout, so no unit test here can prove the text visually wraps. The new test asserts the declaration is emitted on the correct rule, which is why I extract the single rule block rather than matching against the whole stylesheet — a .form__error-container rename fails the test loudly instead of passing vacuously. Visual confirmation in Firefox (where #14930 was reported) still needs a human or a browser-integration test; say the word if you'd like me to add one under dev-packages/browser-integration-tests instead.

I also could not see the screenshot on #14930 render, so I confirmed the root cause from source rather than from the reported repro.

---

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).
• Link an issue if there is one related to your pull request.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 13a469a. Configure here.}