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

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.

Start by reviewing the README's required-deps list and PR #311, then inspect how dependency versions are currently exposed to consumers. Compare publishing a ds-spring-user-framework-bom or Gradle platform with the api and documentation alternatives. Done means one chosen approach is implemented or documented, with the explicit spring-retry pin handled consistently.