chore(release): prepare v0.1.3

[aksOps]

Release-prep PR for v0.1.3.

What's in here

1. Bump SONAR_BUNDLE_VERSION to 0.1.3 in plugin/skills/sonar-predictor/config.env. The skill launcher (bin/sonar) reads this to decide which sonar-predictor-dist-<version>.zip to fetch from Maven Central on first invocation. Before this PR it pointed at 0.1.1, which would have made every v0.1.3 install download the wrong bundle.

2. Add a CI step to publish.yml that sed-bumps the pin to the derived release version right after the Maven versions:set step. After this PR merges, future release tags don't need a separate config.env bump commit — the workflow guarantees the deployed bundle's pin matches the tag.

How v0.1.3 will be cut once this is merged

git checkout main && git pull
git tag -a v0.1.3 -m "Release 0.1.3"
git push origin v0.1.3

The publish.yml workflow then:

• derives 0.1.3 from the tag
• sets pom versions
• syncs config.env
• builds, GPG-signs and deploys protocol/daemon/cli (plus the parent sonar-predictor-parent-0.1.3-src.zip) to Maven Central via the Sonatype Central Portal
• creates a GitHub Release attaching the whole-repo source zip and the assembled sonar-predict-skill-0.1.3.zip

Test plan

• mvn clean package green (156 tests pass)
• CVE scan: 0 CRITICAL, 1 HIGH (commons-beanutils transitive — unreachable on local UNIX socket architecture, documented separately)
• After merge: the workflow run completes both Maven Central deploy and GitHub Release
• After release: gh release download v0.1.3 -p 'sonar-predict-skill-*.zip', extract, run SONAR_PREDICTOR_HOME=... bin/sonar --version — verify pin in the extracted config.env reads 0.1.3

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud