Postgres migrations fail on a fresh database

## What happened

Running a full migration against a brand-new PostgreSQL database, two separate SonarQube plugin migrations fail because they try to DROP a constraint/index that the migration assumes already exists from an earlier step, but doesn't on Postgres:

1. Migration 20230927145127 ("modify file_metrics_key length")

`ERROR: constraint "_tool_sonarqube_file_metrics_pkey" of relation "_tool_sonarqube_file_metrics" does not exist (SQLSTATE 42704)
ALTER TABLE _tool_sonarqube_file_metrics DROP CONSTRAINT _tool_sonarqube_file_metrics_pkey`

2. Migration 20260701000000 ("change_issue_code_block_component_type")

`ERROR: index "idx__tool_sonarqube_issue_code_blocks_component" does not exist (SQLSTATE 42704)
(from DropIndexes("_tool_sonarqube_issue_code_blocks", "idx__tool_sonarqube_issue_code_blocks_component"))`

### Environment:
- DevLake version: `v1.0.3-beta15`
- Database: PostgreSQL 18
- Deployment: official Helm chart with external DB_URL

### Workaround

We excluded the plugin by mounting an empty directory where the sonarqube plugin would be installed otherwise.

```volumes:
- name: exclude-sonarqube-plugin
emptyDir: {}
containers:
- name: lake
volumeMounts:
- name: exclude-sonarqube-plugin
mountPath: /app/bin/plugins/sonarqube
```

This is pretty hacky and we are wondering if this could be fixed in the helm-chart. it works fine for using MySQL but we have requirements to use Postgres.

Reproduce a full migration on a fresh PostgreSQL 18 database using the official Helm deployment. Inspect migrations 20230927145127 and 20260701000000, especially the reported DROP CONSTRAINT and DropIndexes operations. Done means the SonarQube plugin migrations complete on PostgreSQL without excluding the plugin or relying on the workaround.

Written by the indexing model from the issue text.