fix(ui): start with an anti-aliasing the graphics device can't do (#329)

Choosing 8x anti-aliasing in Preferences › Graphics on a device that
only allows 1x and 4x for the window's format made every later start
panic in wgpu's pipeline validation (`Sample count 8 is not supported
by format Bgra8Unorm on this device`), so the app could not be opened
again without editing graphics.json by hand.

- egui-wgpu (vendored): request TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES
  when the adapter has it (WebGPU only guarantees 1x and 4x), and clamp
  the sample count to the largest one the device supports for both the
  colour target and the depth/stencil format. The supported counts are
  exposed as `RenderState::msaa_supported`.
- At start, a saved count the device can't do goes back to the default
  (4x, or the largest supported count below it), is written back, and a
  "Settings were changed" notice says what changed.
- The Anti-aliasing list greys out unsupported counts, `ui.prefs`
  rejects them, and an invalid saved `msaa` loads as the default.
- New messages translated in en, de, ja and ko.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

vendor/README.md

@@ -87,3 +87,9 @@ SolidCraft changes:
   exposing the effective sample count so host paint callbacks can match it.
 - `src/winit.rs`: use that same effective count for depth and resolve attachments.
 - Other backends retain requested MSAA, without another adapter or device probe.
+- `src/lib.rs`: clamp MSAA to the largest sample count the device supports for the surface and
+  depth formats (`supported_msaa_samples`, `RenderState::msaa_supported`): a saved 8x on a
+  device without it failed pipeline validation, a panic at start.
+- `src/setup.rs`: the default device requests `TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES` when
+  the adapter has it, so 2x and 8x work where the adapter supports them (WebGPU only
+  guarantees 1x and 4x).