Track spring-retry version via BOM instead of pinning in consumer builds

Inizia esaminando l’elenco delle required-deps nel README e la PR #311, quindi verifica come le versioni delle dipendenze siano attualmente esposte ai consumer. Confronta la pubblicazione di una ds-spring-user-framework-bom o di una Gradle platform con le alternative api e documentazione. Il lavoro è completato quando è stato scelto e implementato o documentato un approccio e il pin esplicito di spring-retry è gestito in modo coerente.

Background

PR #311 pinned spring-retry:2.0.12 in the README's required-deps list because Spring Boot's BOM doesn't always manage spring-retry for consumers. This works but has a downside: when Spring Boot eventually starts managing spring-retry in its BOM, consumers with the explicit pin may end up with a version drift or redundant constraint.

Goal

Publish a Gradle platform BOM (or at minimum document a BOM-based approach) so consumers can rely on dependency management rather than explicit version pins for spring-retry.

Options to consider

1. Publish a ds-spring-user-framework-bom Maven BOM / Gradle platform that declares managed dependency versions.
2. Use api (instead of compileOnly) for spring-retry so it's transitively available to consumers — though this conflicts with the library's "starters as compileOnly" philosophy.
3. Wait until Spring Boot's BOM manages spring-retry and remove the pin from the README at that point.

Priority

Low — the explicit version pin in the README is a working solution. This is a clean-up / DX improvement for a future release.