Document the release lines and their maintenance branches

Every Spark line now has a maintenance branch, so replace the prose list of supported versions with a table that maps each line to its artifact and links to its branch. Note that the 1.X.Y line carries a different artifactId in the GitLab registry than it did on archiva, which is otherwise easy to trip over when looking for it.

Explain the one genuinely confusing part of the layout: the newest line is always held both by main and by its own maintenance branch, so it is ambiguous where its releases should be cut from. Spell out that they are cut from main while that is the case, that spark358-maintenance is a dormant placeholder until main moves to a newer Spark, and what the handover involves.

Also record why the maintenance branches carry CI overrides. The wmf-maven-ci component gates both pipeline creation and mvn-release on the default branch, and the workflow: override in particular is non-obvious: without it a push to a maintenance branch produces no pipeline whatsoever, with no error to explain why. The protected-branch requirement for $REPOSITORY_WRITE_TOKEN has the same character.

Assisted-by: Claude Opus 5 Bug: T435126