A instituição de uma equipe é inferida da tabela de governança do banco de problemas #270

O que está errado

A instituição pela qual uma equipe compete é inferida da tabela de
governança do banco de problemas.

O próprio código registra isso, em app/Services/Clics/OrganizationMembershipLookup.php:9-16:

"Issue #195 -- a organizacao de uma equipe. Nao existe
users.organization_id: o vinculo mora em OrganizationMembership (#46)."

E a resolução é esta:

self::$cache[$id] = OrganizationMembership::where('user_id', $id)
    ->orderBy('id')
    ->value('organization_id');

organization_memberships foi criada no #46 para responder "quem pode
editar as etiquetas e o dono dos problemas desta organização" — é permissão
sobre acervo, com coluna role cujo padrão é editor. Está sendo lida como
"por qual instituição esta equipe compete", que é outra pergunta.

O que isso produz na prática

E organizations guarda o mínimo — id, name, archived_at, timestamps.
Sem identificador externo, sem nome formal, sem país.

Por que isso passa a importar agora

Um ranking nacional por instituição não se sustenta sobre inferência. Se
duas edições discordarem sobre a qual universidade uma equipe pertence, o
agregado nacional fica errado — e ninguém consegue auditar por quê, porque a
resposta depende de qual linha de permissão de banco de problemas tem o menor
id.

Esta issue é pré-requisito do pacote de resultados.

O que fazer

1. Vínculo próprio, separado da governança. A afiliação do competidor
precisa de mecanismo dedicado — a pergunta "compete por" não é a pergunta
"pode editar o acervo de". Duas perguntas, dois mecanismos.

A decisão de modelagem fica para o PR, mas registre a razão de cada escolha: o
vínculo é do usuário (vale para todas as provas) ou da participação
naquele contest (uma equipe pode representar instituições diferentes em
edições diferentes)? A segunda é mais fiel à realidade e mais cara; a primeira
é mais simples e cobre o caso comum.

2. organizations ganha identidade externa. O que a Contest API da ICPC
define para o recurso organizations e nós não temos:

• icpc_id — o identificador da instituição no cadastro da ICPC
• formal_name — hoje formal_name é preenchido com o mesmo name
  (ClicsPresenter.php:184)
• country — código do país

3. A Contest API passa a dizer a verdade. ClicsPresenter::teams()
(linha 153) monta organization_id a partir do lookup acima. Com vínculo
próprio, passa a ler o vínculo próprio.

4. De quebra: teams() não emite icpc_id. A coluna users.icpc_id
existe desde o #89 e a Contest API define icpc_id no recurso de equipe —
mas ClicsPresenter::teams() (linhas 155-163) não o inclui. Sem ele, o
consumidor da Contest API não consegue casar a equipe com o cadastro nacional.

5. Migração do que existe. Instalações que já usam a inferência precisam
de caminho: derivar o vínculo novo a partir do atual, e listar os casos
ambíguos (múltiplas organizações) para o organizador resolver à mão, em vez
de escolher por ele. O IcpcReportBuilder::teamsMissingIcpcId() já é o
precedente desse padrão — apontar o que falta em vez de inventar.

Como verificar

• Equipe sem membro de banco nenhum tem instituição na Contest API.
• Usuário em duas organizações produz afiliação determinística, e não a
  primeira por id.
• Quem edita o banco de uma instituição e compete por outra aparece com a
  instituição pela qual compete.
• Mutação: apontar a resolução de volta para OrganizationMembership —
  os três testes acima têm de cair.
• A Contest API continua com integridade referencial: toda
  organization_id citada em teams existe em organizations (é o requisito
  duro que o Contest API da ICPC e event feed: nenhuma ferramenta padrão de prova conversa com esta instalação #195 estabeleceu).

Fora de escopo

• O pacote de resultados em si — issue separada, que depende desta.
• Importar cadastro de instituições de fonte externa.