[Refactor/Chore] Reduce toast noise in web: toasts only for results the user cannot see #43802

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for refactors or chores; if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Description

Direction

A toast reports a result the user cannot see where they acted. It is the last choice for feedback, not the default.

1. If the result is visible where the user acted, add nothing.
2. If feedback can live at the trigger (button state, inline message, field error), put it there.
3. Otherwise a toast is appropriate.

Possible rules

These are the working rules; web/docs/toasts.md (added in #43801) is the source of truth and may change as cases come up.

• No success toast when the control itself shows the new value: switch, select, toggle, rating, inline edit.
• No success toast when a dialog closes onto a surface that already shows the created, changed, or removed item.
• Copy feedback belongs on the button, not in a toast.
• A success toast is fine when the result is off screen: a background job started, an export finished, the action left the page that showed its subject. The message names what happened.
• The request layer owns server error toasts. A caller presents a request error itself only by making the request silent and showing it inline.
• Validation is shown at the field, never in a toast.

Motivation

In web/, a toast has become the default completion signal of a mutation. Much of it tells users something they can already see, or something another layer already told them:

• A success toast after a switch, select, or rename whose result is visible in place.
• Generic messages such as "Action succeeded" or "Modified successfully" that carry no information.
• A caller-side error toast on top of the one the request layer already shows for the same failure.
• Client-side validation reported through a toast instead of at the field.

Toasts that appear this often stop being read, including the ones that matter.

Additional Context

Open questions:

• Feedback for saves that stay on the page.
• A flexible copy-feedback component for buttons the current one does not fit.
• "Please wait" and "no permission" toasts that stand in for a disabled state.

Migration is incremental, in small PRs that link here.