fix: recupera trabalho perdido no squash merge e corrige schema/dataload contra o banco real

[Megueutu]

Objetivo

Duas coisas, descobertas ao rodar o dataload de verdade contra o qa:

1. A PR feat: adiciona username e banner ao usuario #12 foi squash-mergeada guardando só o primeiro commit (schema
   com username/banner). Os outros 6 commits depois dele — a
   reestruturação do dataload.py (conexões separadas auth/core), as
   correções de coluna, os CSVs de imagem/texto em português,
   connection.py/Makefile, remoção de scripts/databases.py — nunca
   entraram no main. Esta PR recupera tudo isso a partir da branch
   feat/user-profile-fields.
2. Corrigi mais desvios reais entre db/core/schema.sql e o banco
   coredbqa de verdade, achados só rodando o dataload contra ele (a
   auditoria anterior, feita comparando schema.sql com as entidades Java,
   não pegou tudo).

Alterações

Recuperado da PR #12 (perdido no squash merge):

• dataload.py com conexões separadas para authdb/coredb.
• connection.py/Makefile corrigidos (nome de banco local vs qa,
  migrate/reset com bug de path).
• CSVs de catálogo (scripts/data/catalog/) e banners curados do Unsplash
  (scripts/data/cloudinary/banner.csv).
• Remoção de scripts/databases.py (substituído por lógica mais simples
  em connection.py).

Novo, achado rodando contra coredbqa/authdbqa reais:

• company.fk_address/fk_business_contact, local_unit.fk_address,
  technician_affiliation.fk_company,
  technical_project.fk_requester/fk_local_unit/status/start_date
  são NOT NULL no banco real — o dataload.py tratava como opcionais
  (maybe()). Corrigido.
• certification tem estrutura bem diferente na realidade
  (fk_technician, type, information obrigatórios; name/issuer/
  description/validity opcionais) — reescrevi seed_certification e
  movi pra rodar depois de seed_technician (agora depende dele).
• Tabela technical_company existe no banco real e eu não sabia —
  adicionada ao schema.sql/migration (sem seed próprio ainda, fora do
  pedido original).
• federated_identity (UNIQUE(user_id, issuer)) e inventory
  (UNIQUE(fk_supplier, fk_model)) têm constraints compostas que o sorteio
  aleatório com reposição violava em volumes maiores — corrigido pra
  sortear sem reposição/deduplicar.
• db/core/seed.sql: o segundo INSERT INTO company também não tinha
  fk_address/fk_business_contact — mesmo problema, corrigido.

Endpoints afetados

Nenhum (mudanças de schema/seed/dataload, sem tocar em API)

Banco de Dados

• Schema
• Seed

Como validar

make schema TARGET=core && make enums TARGET=core && make indexes TARGET=core
make schema TARGET=auth && make enums TARGET=auth && make indexes TARGET=auth
make dataload ROWS=200

Já validei isso de verdade, duas vezes: uma vez contra um Postgres
descartável local, e uma vez contra o coredbqa/authdbqa reais (com
ALTER TABLE aplicado manualmente por você pra adicionar
username/banner, já que a PR #12 nunca migrou o banco de verdade — só
a entidade Java). As duas rodaram de ponta a ponta sem erro.

Evidências

Sem evidências visuais (mudança de schema/dados, não de UI)

Closes #

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sonarqubecloud]

Quality Gate failed

Failed conditions
29.4% Duplication on New Code (required ≤ 3%)
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE