Homebrew formula clashes with formula produce by Boot 4.1

The spring-boot.rb Homebrew formula in spring-io/homebrew-tap tracks
both the 3.5.x maintenance line and the 4.0.x line in the same formula
file. The spring-builds bot alternates between the two lines on
nearly every release, sometimes upgrading to the 4.x line first and
then reverting to 3.x shortly after, and sometimes the other way
around, for example:

• 2026-06-25: Upgrade to Spring Boot 3.5.16
• 2026-06-10: Upgrade to Spring Boot 4.1.0 → then Upgrade to Spring Boot 4.0.7 → then Upgrade to Spring Boot 3.5.15
• 2026-04-23: Upgrade to Spring Boot 4.0.6 → then Upgrade to Spring Boot 3.5.14
• 2026-03-26: Upgrade to Spring Boot 3.5.13 → then Upgrade to Spring Boot 4.0.5
• 2026-03-19: Upgrade to Spring Boot 4.0.4 → then Upgrade to Spring Boot 3.5.12
• 2026-02-19: Upgrade to Spring Boot 3.5.11 → then Upgrade to Spring Boot 4.0.3
• 2026-01-22: Upgrade to Spring Boot 3.5.10 → then Upgrade to Spring Boot 4.0.2

Full commit history: https://github.com/spring-io/homebrew-tap/commits/main/spring-boot.rb

Because the formula only ever points at a single URL/version at a time,
the outcome of brew install spring-boot or brew upgrade depends
entirely on which of the two lines the bot last committed at the
moment the user runs the command — not on any explicit choice by the
user. Two users installing on different days can end up with a 3.x or
a 4.x CLI without ever intending to pick a specific major version.

Since Homebrew never downgrades a formula automatically, this also
means a user who happens to install while the formula points at 4.0.x
stays on that version indefinitely once the bot flips back to 3.5.x,
since brew upgrade will not revert them to a "lower" tracked version.
brew info then reports the 3.5.x line as current/stable while the
installed keg silently remains on 4.0.x, with no indication that this
happened due to timing rather than intent.

Suggested fix: split the formula into two, following the standard
Homebrew convention for parallel major release lines, e.g.:

• spring-boot → tracks the primary/latest line
• spring-boot@3 → tracks the 3.x maintenance line

This would let users explicitly choose which major version to install
and upgrade, instead of the outcome being determined by upgrade timing.

Happy to provide more detail or help test a fix if useful.

Start with the spring-boot.rb formula in the spring-io/homebrew-tap repository and review its commit history to understand how the 3.5.x and 4.x updates alternate. Check Homebrew's convention for parallel major-release formulas, then verify that spring-boot tracks the primary line and spring-boot@3 tracks the 3.x maintenance line independently.