chore: Bump 2.346 profile to .1 and bump 2.332 to .4

[NotMyFault]

The PR bumps the latest LTS release to the first point release and bumps the second last LTS release to the final security release.

[jglick]

Somehow the current doc shows 2.332.3, FYI @daniel-beck (context: jenkins-infra/jenkins.io#4876)

[daniel-beck]

https://github.com/jglick/jenkins.io/blob/aed4f7fd2d70b6325d447d00588d9d86c0acd2a8/content/_layouts/corebaseline.html.haml#L13 is just https://updates.jenkins.io/tiers.json via https://github.com/jenkins-infra/jenkins.io/blob/64ed7120a01fde6d35946423e35da51e4a95fca3/scripts/fetch-external-resources#L54-L55 and it lists versions actually used as dependency only (so we can generate matching update sites).

By now there's half a dozen plugins that depend on 2.332.4, so the site is (currently) fixed.

[jglick]

⇒ jenkins-infra/jenkins.io#5320

[jetersen]

@NotMyFault FYI these versions are now fully managed by https://github.com/jenkinsci/bom/blob/master/updatecli/generate-manifests.ps1

I noticed however a bug after reviewing this PR 😅
Potentially a 2.446.x can be set as x.y I assumed in the script it could only be x.y.z let me write a fix 😅

[jetersen]

#1344 should correctly handle jenkins.version for weekly or stable whether it is x.y or x.y.z

[NotMyFault]

@NotMyFault FYI these versions are now fully managed by https://github.com/jenkinsci/bom/blob/master/updatecli/generate-manifests.ps1

I noticed however a bug after reviewing this PR 😅 Potentially a 2.446.x can be set as x.y I assumed in the script it could only be x.y.z let me write a fix 😅

Nice, I assume we no longer need to raise PRs to update existing profiles from one point release to another?

[jetersen]

Nice, I assume we no longer need to raise PRs to update existing profiles from one point release to another?

Indeed that is the case 👏

Only need to raise PRs when new LTS line comes out.

But potentially that could be automated too 😉