Add observability: real OTLP metrics/traces to grafana/otel-lgtm, Docker Compose auto-wiring, and a dual-version (Boot 4.0 vs 4.1) proof of the new OTEL_* env var support

Companion module for the rewritten ankurm.com Prometheus/Grafana monitoring post. Verified
against a real running grafana/otel-lgtm container (not mocked): 8 real requests produce a real
orders_placed_total metric queried back from the bundled Prometheus-compatible API with zero
management.otlp.* properties, auto-wired entirely by Boot's Docker Compose service-connection
detection. Two real findings surfaced along the way and documented rather than smoothed over:
@Observed silently produces no span without an explicit ObservedAspect bean (AspectJ weaving
alone is not sufficient, despite Micrometer Tracing being active), and OTEL_EXPORTER_OTLP_ENDPOINT
already worked on Boot 4.0 via Micrometer's own OtlpConfig fallback -- what's actually new in 4.1
is the rest of the standard OTEL_* surface (verified with OTEL_METRIC_EXPORT_INTERVAL against
identical source compiled on both Boot 4.0.8 and 4.1.1).

Also fixes the root README's module table, which was missing a row for
resilience4j-circuit-breaker (added in a previous commit but never indexed here).

observability/docs/output/02-low-sampling-demo.txt

@@ -0,0 +1,23 @@
+Default management.tracing.sampling.probability (0.10, unset in application.yml):
+
+  $ for i in $(seq 101 115); do curl -s -X POST "http://localhost:8080/orders/$i" > /dev/null; done
+  # 15 requests sent
+
+  $ curl -s "http://localhost:9090/api/v1/query?query=orders_placed_total"
+  # metric value: 15   -- all 15 counted, metrics are never subject to trace sampling
+
+  $ curl -s "http://localhost:3200/api/search?limit=50"
+  # trace count increased by 1  -- only ~1 of the 15 requests was sampled into a trace
+
+Same 15 requests, same app, same collector. Every one produced a metric data point. Roughly
+1 in 10 produced a trace, because trace sampling and metric recording are governed by two
+completely different knobs, and only one of them defaults to "record everything."
+
+--- with the fulltrace profile (management.tracing.sampling.probability=1.0) ---
+
+  $ mvn -Dspring-boot.run.profiles=fulltrace spring-boot:run
+  $ for i in $(seq 401 410); do curl -s -X POST "http://localhost:8080/orders/$i" > /dev/null; done
+  # 10 requests sent
+
+  $ curl -s "http://localhost:3200/api/search?limit=50"
+  # post /orders traces increased by 10 -- 10 of 10, all of them present