[P3][chore][deps] Revisar filelock 4.x depois do virtualenv >= 21.13 (a partir de 2026-10-03) — #2001 fechado, Dependabot passa a ignorar a major

[FabioLeitao]

Contexto

O PR #2001 (Dependabot: filelock 3.32.7 → 4.0.0, versão major) foi fechado por decisão do operador em 28/set/2026
por estar bloqueado, sem defeito no filelock em si.

Por que estava bloqueado (verificado)

• O filelock é dependência apenas transitiva (huggingface-hub, python-discovery/virtualenv via pre-commit, entre
  outras); não está no pyproject.toml.
• O virtualenv 21.9.0, que está no uv.lock, exige filelock<4. Por isso o resolvedor não conseguia aceitar a 4.x, o
  uv.lock não mudou e o Dependabot só alterou o requirements.txt, deixando os dois arquivos desencontrados.
• O virtualenv 21.13.0 (publicado em 2026-09-26) já exige filelock<5. Com a espera de 7 dias do repo
  (cooldown: default-days: 7), ele só fica elegível a partir de 2026-10-03.

Atenção: fechar o PR faz o Dependabot IGNORAR essa versão major

Fechar (ou @dependabot close) cria uma regra de ignorar: o Dependabot não vai propor o filelock 4.x de novo sozinho.
Esta issue existe para não perdermos o assunto.

O que fazer (a partir de 2026-10-03)

1. Esperar o Dependabot propor o virtualenv ≥ 21.13 (ou fazê-lo à mão, se preferir), e mesclar.
2. Só então tentar o filelock 4.x: uv lock --upgrade-package filelock, e regenerar requirements.txt e pylock.toml
   (procedimento em docs/ops/DEPENDABOT_REQUIREMENTS_SYNC.md).
3. Antes de mesclar, ler as notas de release do filelock 4.0.0. As que consultei só citam o conserto do soft-rw, sem
   lista de quebras; confirmar no changelog completo.
4. Se o Dependabot continuar ignorando, remover a regra de ignorar (reabrir o deps(uv): bump filelock from 3.32.7 to 4.0.0 #2001 ou @dependabot recreate).

Critério de aceite

• virtualenv ≥ 21.13 no uv.lock.
• filelock 4.x no uv.lock, com requirements.txt e pylock.toml regenerados e check-all com exit 0.

— Claude (Opus 5.5, T14) · auditor, tom recomendatório