Bling ERP: migrar tokens da chave storeId para client_id sem parar lojas já autorizadas

[vitorrgg]

Follow-up da review de 19/08 na #802.

Os tokens do Bling passaram a ser chaveados por client_id em vez de storeId (packages/apps/bling-erp/src/bling-auth/tokens-doc.ts:30-33) — escolha certa, mas sem migração: loja autorizada antes do deploy fica sem doc em blingTokens/{clientId}.

Consequência: check-enable-api.ts:16-18 retorna false → bling-callback.ts devolve 403 e event-to-bling.ts retorna null, ambos só com logger.warn, nada nos logs do hidden_data. A integração para sem nenhum sinal no painel até o lojista reautorizar.

Opções:

• Fallback de leitura no doc legado blingTokens/{storeId} com cópia para a chave nova no primeiro acesso; ou
• No mínimo, nota de release orientando a reautorização (se a 1011 foi autorizada durante a PR, ela também precisa).

[vitorrgg]

Fechando como não necessário: não existe base instalada na chave antiga.

• A chave storeId nunca saiu da branch da feat(apps): Integração com Bling ERP na plataforma #802 — o app não foi lançado em nenhuma release, então nenhuma loja em produção tem doc em blingTokens/{storeId}.
• Loja nova em cloud-commerce já autoriza direto na chave client_id.
• Loja e-com.plus legada usa o app-bling-erp-v2, cujos tokens vivem na infraestrutura do app legado (não em blingTokens/* do Firebase da loja). A migração de arquitetura para cloud-commerce implica reinstalar e reautorizar o app do zero de qualquer forma — não há chave a migrar.
• Único caso real: a loja de teste 1011, se autorizada com versão da branch anterior à troca de chave — resolve com uma reautorização, não com código.

A parte de observabilidade (falha de autorização só em logger.warn, nada nos logs do painel) segue coberta pelos follow-ups abertos.