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

Comienza revisando la lista de required-deps del README y el PR #311; después, inspecciona cómo se exponen actualmente las versiones de las dependencias a los consumidores. Compara la publicación de un ds-spring-user-framework-bom o una plataforma de Gradle con las alternativas de api y documentación. Se considera terminado cuando se haya implementado o documentado un enfoque elegido, gestionando de forma coherente la fijación explícita de spring-retry.

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.