fix: release and sonar cleanup

[ansh-info]

For authors

Description

This PR cleans up the release and quality-analysis pipeline in AIAgents4Pharma.

It removes the mixed Node/Python release setup, makes python-semantic-release the single
release authority, simplifies Docker publishing to a tag-driven flow, and rewrites the SonarCloud
workflow so it no longer depends on cascading workflow_run artifact chains.

What Changed

Release pipeline

• replaced legacy Node semantic-release with python-semantic-release
• made pyproject.toml the version source of truth
• removed package.json and package-lock.json
• removed the old docker_compose_release.yml workflow
• updated the main release workflow to:
  • create the semantic release
  • build and validate Python artifacts
  • publish to PyPI
  • attach compose bundles as release assets
• changed Docker publishing to trigger from release tags (v*) instead of workflow_run

SonarCloud

• replaced the old artifact-download workflow_run model with a self-contained SonarCloud
  workflow
• SonarCloud now generates its own:
  • coverage XML
  • pylint JSON
  • bandit JSON
• removed dead Sonar artifact upload steps from the test workflows
• tightened Sonar exclusions for tracked non-source files such as:
  • .venv
  • .egg-info
  • .env
  • .DS_Store
  • Dockerfiles
  • install docs
  • generated/build output
• reduced low-value duplication noise by excluding boilerplate paths from duplication checks

Docs

• added RELEASING.md
• updated workflow and operations docs to match the new release/Sonar model
• reset CHANGELOG.md to a clean semantic-release-managed baseline

Why

The previous setup had several problems:

• mixed release authority across Node and Python
• version mutation through shell patching of pyproject.toml
• cascading workflow dependencies
• noisy duplicated GitHub release bodies
• fragile SonarCloud analysis depending on partial artifacts from other workflows

This PR makes the release boundary tag-driven and simplifies the CI model so each workflow owns
its own responsibility.

Validation

Verified locally:

• uv sync --frozen --extra dev
• uv build
• uv run twine check dist/*
• uv run semantic-release version --print
• all GitHub workflow YAML files parse successfully

Fixes # (issue) Mention the issue number.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests you conducted to verify your changes. These may involve creating new test scripts or updating existing ones.

• Added new test(s) in the tests folder
• Added new function(s) to an existing test(s) (e.g.: tests/testX.py)
• No new tests added (Please explain the rationale in this case)

Checklist

• My code follows the style guidelines mentioned in the Code/DevOps guides
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. MkDocs)
• My changes generate no new warnings
• I have added or updated tests (in the tests folder) that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

For reviewers

Checklist pre-approval

• Is there enough documentation?
• If a new feature has been added, or a bug fixed, has a test been added to confirm good behavior?
• Does the test(s) successfully test edge/corner cases?
• Does the PR pass the tests? (if the repository has continuous integration)

Checklist post-approval

• Does this PR merge develop into main? If so, please make sure to add a prefix (feat/fix/chore) and/or a suffix BREAKING CHANGE (if it's a major release) to your commit message.
• Does this PR close an issue? If so, please make sure to descriptively close this issue when the PR is merged.

Checklist post-merge

• When you approve of the PR, merge and close it (Read this article to know about different merge methods on GitHub)
• Did this PR merge develop into main and is it suppose to run an automated release workflow (if applicable)? If so, please make sure to check under the "Actions" tab to see if the workflow has been initiated, and return later to verify that it has completed successfully.

[gitnotebooks]

Review these changes at https://app.gitnotebooks.com/VirtualPatientEngine/AIAgents4Pharma/pull/346

[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