Add distribution-owned response feedback UI

[comp615]

This PR description was generated by AMP.

Summary

Berd distributions need a generic way to collect turn-level response ratings without putting a company-specific telemetry endpoint or schema in the public app.

This adds opt-in thumbs-up/down controls tied to the canonical assistant response, session ID, and message ID. Stock Berd uses a typed no-op transport and ordering seam; distributions can supply their own sink and enable the UI through the transport-neutral feedbackSurveys build capability plus runtime config. Mounting, hovering, focusing, or revealing controls emits nothing; only explicit good, bad, and cleared transitions reach the sink.

Related issue

N/A — no duplicate issue or PR found.

Testing

bin/just check
bin/pnpm vitest run src/features/chat/response-feedback src/shared/runtime-config/schema.test.ts
bin/just _tauri-cargo-unix check --features block-feedback

AI tool validation prompt

Copy and paste into your AI tool:

Review block/berd branch ccroom/response-feedback-ui and verify:
1. Run the focused response-feedback and runtime-config tests.
2. Confirm stock Berd sends no feedback events, while the typed sink receives session ID, message ID, appearance ID, and response only when the user changes a rating; confirm the distribution sink owns delivery ordering.
3. Confirm only the canonical terminal assistant response receives controls in classic and virtual transcripts.

[kalvinnchau]

🤖 Reviewed in the context of the stacked session-survey work and a distribution-owned transport. These comments are limited to unresolved contracts owned by this PR; later-stack concerns are left on the PR that owns them.

[kalvinnchau]

🤖 Is the admin runtime-config endpoint guaranteed to version responses by client? RuntimeFeedbackConfig uses deny_unknown_fields, but this adds a field while retaining schema version 1. An older managed client receiving the new field rejects the entire endpoint response and falls back to cache/default policy; the stacked survey PR adds another field under the same v1 shape. If mixed client versions can reach one endpoint, this needs an extensible field or negotiated schema response rather than an undeclared additive v1 change.

[comp615]

Confirmed the compatibility risk is conditional on the service contract. The client sends no visible schema/client negotiation signal, so I avoided a speculative local version change that would not protect already-shipped strict v1 clients. Can mixed Berd versions receive the same /desktop/v1/runtime-config response, and if so what service-side signal shapes fields for each client? — Amp 🤖