UX robustness: submit feedback, focus, and no-JS fallback

Problem/Motivation

Four interaction defects affect keyboard, screen-reader and no-JS users, and one affects every reader who posts a comment.

Submitting a comment gives almost no visible feedback. The handler sets aria-busy on the form (js/comment-form.js:117), sets form.inert (:129), disables the buttons, and prepends a small "Submitting comment..." status line to the top of the form (:83-93). But there is no CSS rule for a busy form: the only [aria-busy="true"] rule in the module is comment.css:223, scoped to .act-comment-approval, and [data-act-form-feedback] carries only a margin (comment-form.css:20). inert applies no visual treatment of its own. So after a long comment the only cue inside the viewport is that the Save button stops looking clickable, while the status line sits at the top of the form, potentially well above the fold. Reported from real use: "the buttons went disabled, and I did see a small message at the top of the form ... but if my comment was longer I might not've seen that."

The same status line is also unlikely to be announced. On the first submission of a page, the live region is created and populated in a single synchronous task (js/comment-form.js:83-93), and live regions must exist in the accessibility tree before their content changes. Every other announcement in the file is backed by Drupal.announce; this one is not.

After a validation error, focus is lost to the top of the document because the errored node is replaced and the error branch never restores it. Branch expansion gives no busy/loading feedback and can fail silently, with no re-entry guard and no catch on the failure announce. With the default density, a no-JavaScript reader sees subject lines and bylines but zero comment bodies, no show-all link, and several JS-only controls rendered enabled.

Steps to reproduce

• Write a comment long enough that the top of the form scrolls out of view, then press Save; observe that the only in-viewport cue is the disabled buttons, with no spinner, no dimming, and no message near the button.
• Submit the first comment of a page with a screen reader; observe "Submitting comment..." is not announced.
• Submit an empty reply; observe focus move to the top of the document.
• Click a caret on a slow branch; observe a multi-second wait with no loading indicator.
• Disable JavaScript; open a default-density thread; observe no comment bodies and enabled JS-only controls.

Proposed resolution

• Give the busy form a visible state. The hook already exists: add a rule for .act-reply-form[aria-busy="true"] / form[aria-busy="true"] that dims and visually locks the form, matching the existing [aria-busy] treatment at comment.css:223.
• Put a cue where the reader is looking: a spinner or "Saving..." label adjacent to the Save button, not only at the top of the form. Consider also pinning the status line to the form's action row rather than prepending it.
• Announce submission start via Drupal.announce, or render an empty [data-act-form-feedback][role=status] container server-side in InlineReply::alter() so the live region pre-exists its first mutation.
• Restore focus to a sensible target (the invalid field or the feedback node) after a validation error.
• Add aria-busy/loading state, a re-entry guard, and a visible error path to branch expansion.
• Hide JS-only controls when JS is absent; render a show-all link; consider a non-empty default density.

Remaining tasks

• Verify the busy state is visible without scrolling on a comment long enough to push the form header off screen.
• Verify keyboard, screen-reader and no-JS flows.

User interface changes

Adds a visible saving state on the comment form and a cue next to the Save button, restores focus after errors, adds loading feedback, and makes no-JS content usable.

API changes

None anticipated.

Data model changes

None anticipated.