fix(sonarqube): support long issue code block components

[DoDiODev]

Motivation

SonarQube issue code block component paths can exceed both the domain layer's previous default string length and the tool layer's varchar(500) limit. This causes conversion failures such as Data too long for column 'component'.

Changes

• change SonarqubeIssueCodeBlock.Component and CqIssueCodeBlock.Component to TEXT
• remove the component indexes, which cannot be retained on unbounded TEXT columns consistently across supported databases
• add and register tool- and domain-layer migrations
• drop indexes through the database-neutral DAL DropIndexes API and propagate errors
• add regression coverage for model tags, schema upgrades, data preservation, and component values longer than 500 characters

Explicitly excluded

• unrelated migrations and dependency upgrades
• Docker, Compose, Grafana, frontend, and Python changes
• fork-specific files and plugins

Automated validation

• make build
• make -C backend migration-script-lint
• go test ./core/models/migrationscripts ./plugins/sonarqube/models/migrationscripts ./plugins/sonarqube/tasks -count=1
• go test ./plugins/sonarqube/e2e -run '^$' -count=1
• TestSonarqubeIssueCodeBlockLongComponent against MySQL 8.4.10
• TestSonarqubeIssueCodeBlockLongComponent against PostgreSQL 18.1
• git diff --check upstream/main...HEAD

The database tests create the previous indexed VARCHAR schemas, insert existing records, execute both registered migrations, verify the resulting TEXT columns and removed indexes, confirm data preservation, and process values longer than 500 characters.

Manual validation

The reconstructed branch and database migration results were reviewed and approved before commit and push.

Rollback

Revert this commit before release. After the migration has accepted values beyond the old limits, narrowing the columns again requires validating or truncating those values first.

[klesh]

LGTM.
Thanks for your contribution.