bug: deploy de PR (label deploy-flow) rouba deployments de produção pro pool dev

## Sintoma

Work pool de produção (`basedosdados`) tinha caído pra só **22** deployments — deveria ter centenas. Descoberto ao investigar por que produção estava com poucos flows agendados.

## Causa raiz

`.github/scripts/deploy_flows.py`, função `deploy_flow()`, registrava o deployment sempre com `name=flow_name` — **idêntico** entre o caminho de prod (`--pool basedosdados --branch main --all`) e o caminho de PR/dev (`--pool basedosdados-dev`, disparado pela label `deploy-flow`).

O Prefect identifica um deployment pela combinação `/`, não pelo work pool — `work_pool_name` é só um campo mutável do mesmo registro. Como os dois caminhos usavam o mesmo `name`, todo PR com a label `deploy-flow` que tocasse um flow **já deployado em produção** não criava um deployment novo em dev: atualizava o **mesmo registro de produção**, movendo-o pro pool `basedosdados-dev` e zerando o schedule (`is_dev` sempre passa `schedules=None`).

### Evidência concreta

- Pool `basedosdados` (prod): 22 deployments. Pool `basedosdados-dev`: 326.
- `au_abs_population_flow` tem `deploy_schedules` definido no código-fonte (deveria ter agendamento em prod), mas só existia no pool dev, sem nenhum schedule.

## O que já foi feito (mitigação + recuperação)

1. Removida a label `deploy-flow` dos 10 PRs abertos que a tinham, pra evitar novos sequestros enquanto a correção não sobe.
2. Rodado deploy completo de produção (`--all --pool basedosdados --branch main`) pra restaurar os flows sequestrados — 276 registrados, 0 erros. Pool prod voltou pra 298 deployments.
3. Rodado `sync-deployments` no backend pra reconciliar o estado ativo/pausado (208 ativados, 140 pausados, 0 erros).

## Correção (ver PR)

`deploy_flow()` agora usa `name=f"dev-{flow_name}"` no caminho dev, mantendo `name=flow_name` em prod (sem mudar, já que o backend — `sync-deployments`/`set_deployment_schedule_active` — depende desse nome exato pra prod). Cada ambiente passa a ter seu próprio registro, sem nunca competir pelo mesmo pool.

Validado com um flow real (`au_abs_population_flow`): deploy em dev agora cria `dev-au_abs_population_flow`, um ID totalmente separado, sem tocar no deployment de prod.

## Pendência à parte

O pool dev ainda tem ~50 deployments com o nome antigo (sem o prefixo `dev-`), sobra de antes da correção — tratado em issue separada, não é urgente (não têm mais risco de colisão, já que prod foi restaurado).