fix(clickhouse): renumber the external deployment id migration to 041 (#4734)

## Summary

`goose up` against `internal-packages/clickhouse/schema` panics on
`main` today, so ClickHouse migrations cannot be applied from a fresh
checkout. Renumbering the external deployment id migration from 040 to
041 clears it.

## Root cause

Two migrations claim version 40.
[#4615](#4615) added
`040_create_task_events_search_v2.sql`, and
[#4661](#4661) added
`040_add_task_runs_v2_external_deployment_id.sql` a day later. #4661 was
opened before #4615 merged, so 040 was genuinely free at branch time,
and because the two files have different names there is no textual
conflict for git or a rebase to surface. Both merged green, and no
workflow in this repo runs `goose`, so the collision only shows up the
first time someone actually migrates.

goose parses the numeric filename prefix as the version and refuses
duplicates:

```
panic: goose: duplicate version 40 detected:
  .../040_create_task_events_search_v2.sql
  .../040_add_task_runs_v2_external_deployment_id.sql
```

It aborts while collecting the directory, before executing any SQL, so
nothing was half applied and there is no migration state to repair.

This migration gets renumbered rather than the `task_events_search_v2`
one because goose keys on the version number and not the filename:
version 40 is already recorded wherever 040 has been applied, so
renaming that file would re-run an applied migration.

Verified with a full `goose up` against ClickHouse 26.2.19.43 (the image
pinned in `internal-packages/testcontainers`): migrations apply cleanly
through version 41, and `task_runs_v2.external_deployment_id` lands as
`String DEFAULT ''`.

Author: 0ski