responsive fluid/physical scaling, widget-API stabilization, and perf guardrails

Responsive scaling. ltk now offers two first-class ways to size a UI so it adapts across screens, chosen per process via `WidgetScaling { Fluid, Physical }` (`set_widget_scaling` / `widget_scaling`, default `Fluid`). Fluid sizing (`Length::fluid( px )`) makes a design pixel a proportion of the surface's smaller side, calibrated against a reference width (`set_fluid_reference` / `fluid_reference`, 412 px default) and bounded by `FLUID_MIN` / `FLUID_MAX`; physical sizing (`Length::dp( px )`) is a constant-physical-size pixel scaled by display density (`set_density` / `density`). `Length` gains `orient( portrait, landscape )` — resolve one value in portrait, another in landscape — plus `widget( px )`, which picks fluid or dp per the active mode. Canvas exposes `geom_px` (geometry, resolved in physical layout space) and `font_px` (font size, bridging logical / physical per mode) so widgets and apps share one resolution path. Note the rename: `set_design_reference` / `design_reference` became `set_fluid_reference` / `fluid_reference`, and `Length::dp` changed meaning — the old surface-proportional behaviour now lives on `Length::fluid`.
Widgets. Every stock widget resolves its default geometry and font through the widget-scaling mode instead of frozen pixels, so a whole UI scales coherently without per-call units. New size builders where they were missing: `button` gains `font_size` / `height`, `text_edit` gains `height` / `font_size_fluid`, `separator` gains `pad_v`, and assorted widgets accept a `Length` where they previously took only `f32`.
Overlays. `OverlaySpec::size` is now `( Length, Length )` instead of `( u32, u32 )`, resolved against the main surface when the overlay is materialized, so overlays can scale with the display; `Length::px( … )` reproduces the old fixed sizing.
API stabilization (toward 1.0). Widget struct fields are now `pub( crate )` — they are configured through builders, not field access — except the value / state types apps genuinely read or construct (`Time`, `Date`, `ComboState`), which stay public. The internal `test_support` helpers move behind a `test-support` Cargo feature (off by default, so third-party builds never see them; ltk's own `make test` enables it). `Separator` drops its `0.0`-means-mode sentinel for `Option<Length>`, so an explicit `pad_v( 0.0 )` is a real flush divider distinct from the mode-following default.
Performance guardrails. Opt-in diagnostics via `LTK_PERF_WARN=1` warn about stuck animations, sustained software-render animation, and low `poll_interval`; software-rendered animation is capped near 30 Hz to spare CPU on machines that fall back off EGL. Apps can override the cap with `App::cap_software_animation`.
Docs and build. The two scaling modes are documented in README, onboarding and architecture, with the earlier gradient / backdrop doc drift cleaned up. The Makefile now ships the `locales/` directory into the packaged crate (fixing i18n keys rendering raw for downstreams), builds the new `responsive` example, and runs tests with `--features test-support`.

tests/slider_math.rs

@@ -1,4 +1,6 @@
-use ltk::test_support::value_from_x_in_rect;
+#![ cfg( feature = "test-support" ) ]
+
+use ltk::test_support::{ value_from_x_in_rect, thumb_design_px };
 use ltk::Rect;
 
 fn rect( x: f32, y: f32, w: f32, h: f32 ) -> Rect
@@ -6,20 +8,24 @@ fn rect( x: f32, y: f32, w: f32, h: f32 ) -> Rect
 	Rect { x, y, width: w, height: h }
 }
 
+/// The thumb size the pure math is exercised with — the design constant, so
+/// the pad matches what the renderer draws with an unscaled thumb.
+fn thumb() -> f32 { thumb_design_px() }
+
 #[ test ]
 fn left_edge_clamps_to_zero()
 {
 	let r = rect( 0.0, 0.0, 200.0, 36.0 );
-	assert_eq!( value_from_x_in_rect( r, 0.0 ), 0.0 );
-	assert_eq!( value_from_x_in_rect( r, -50.0 ), 0.0 );
+	assert_eq!( value_from_x_in_rect( r, 0.0, thumb() ), 0.0 );
+	assert_eq!( value_from_x_in_rect( r, -50.0, thumb() ), 0.0 );
 }
 
 #[ test ]
 fn right_edge_clamps_to_one()
 {
 	let r = rect( 0.0, 0.0, 200.0, 36.0 );
-	assert_eq!( value_from_x_in_rect( r, 200.0 ), 1.0 );
-	assert_eq!( value_from_x_in_rect( r, 999.0 ), 1.0 );
+	assert_eq!( value_from_x_in_rect( r, 200.0, thumb() ), 1.0 );
+	assert_eq!( value_from_x_in_rect( r, 999.0, thumb() ), 1.0 );
 }
 
 #[ test ]
@@ -28,7 +34,7 @@ fn center_returns_half()
 	// The thumb adds padding on both sides, so the geometric center of the
 	// rect produces ~0.5 (within the THUMB_SIZE/2 tolerance).
 	let r = rect( 0.0, 0.0, 200.0, 36.0 );
-	let v = value_from_x_in_rect( r, 100.0 );
+	let v = value_from_x_in_rect( r, 100.0, thumb() );
 	assert!( ( v - 0.5 ).abs() < 0.1, "expected ~0.5 got {}", v );
 }
 
@@ -36,9 +42,9 @@ fn center_returns_half()
 fn rect_offset_translates_correctly()
 {
 	let r = rect( 500.0, 0.0, 200.0, 36.0 );
-	assert_eq!( value_from_x_in_rect( r, 500.0 ), 0.0 );
-	assert_eq!( value_from_x_in_rect( r, 700.0 ), 1.0 );
-	let v = value_from_x_in_rect( r, 600.0 );
+	assert_eq!( value_from_x_in_rect( r, 500.0, thumb() ), 0.0 );
+	assert_eq!( value_from_x_in_rect( r, 700.0, thumb() ), 1.0 );
+	let v = value_from_x_in_rect( r, 600.0, thumb() );
 	assert!( ( v - 0.5 ).abs() < 0.1, "expected ~0.5 got {}", v );
 }
 
@@ -48,7 +54,7 @@ fn output_is_always_in_unit_range()
 	let r = rect( 10.0, 10.0, 300.0, 36.0 );
 	for x in -100i32 ..= 500
 	{
-		let v = value_from_x_in_rect( r, x as f32 );
+		let v = value_from_x_in_rect( r, x as f32, thumb() );
 		assert!( ( 0.0..= 1.0 ).contains( &v ), "v={} out of range at x={}", v, x );
 	}
 }
@@ -59,7 +65,7 @@ fn very_narrow_rect_does_not_divide_by_zero()
 	// Width < THUMB_SIZE — track_w is clamped to 1.0 internally so the
 	// formula stays defined.
 	let r = rect( 0.0, 0.0, 4.0, 36.0 );
-	let v = value_from_x_in_rect( r, 2.0 );
+	let v = value_from_x_in_rect( r, 2.0, thumb() );
 	assert!( v.is_finite() );
 	assert!( ( 0.0..= 1.0 ).contains( &v ) );
 }