feat: contrato aditivo de linha vazia/degradacao posicional + fases de progresso

[elson-vinicius-lopes]

Summary

• LineInfo.IsDeclaredEmpty / LineInfo.PositionalAlignmentFailed: sinais aditivos de linha (linha vazia declarada no layout, colapso posicional tipo LINHA006). ParsingResult.LineInfos passa a ser populado (antes nunca era).
• Fases discretas de status no indice low-code: uploaded/parsing (client-side), transforming/completed/failed (backend).
• Nenhuma mudanca de Status/comportamento existente — tudo aditivo.

Closes #194, #195, #197 (issue #196 fica de fora — bug ainda bloqueado por correlationId, nao faz parte deste escopo).

Nota de reconciliacao (importante para revisao)

A develop local usada durante a implementacao estava ~20 commits atras de origin/develop,
incluindo o PR #191 (a330af2) que ja corrigia o Bug A/B de InformacoesParaEDI
(ParsedField.Length/OccurrenceCount/IsAggregatedOccurrence). O @lp-parser-llm
reimplementou o mesmo bug do zero sem saber disso.

Ao reconciliar esta branch a partir de origin/develop atualizado (cherry-pick dos 2 commits
locais), a duplicacao foi resolvida: Models/Entities/ParsedField.cs ficou byte-identico
ao de origin/develop apos a resolucao de conflito — confirmando que nenhuma logica divergente
sobrou. Restaram apenas os 2 campos genuinamente novos de LineInfo (+ o fix de
ParsingResult.LineInfos nunca populado).

Test plan

• dotnet build — 0 erros (625 warnings pre-existentes, nenhum novo)
• dotnet test — 378/382 (as 4 falhas sao pre-existentes/nao relacionadas: SafePathResolverTests
  e LowCodeRunnerArgsTests falham por diferenca de path Windows x Linux no ambiente de CI atual)
• PositionalFormatRegressionTests — 4/4 passando isoladamente
• Revisao humana antes do merge (ver observacoes abaixo)

Observacoes para revisao humana

• O commit de fases de progresso (Services/Transformation/LowCode/) nao teve conflito com o
  reconciliado acima — areas de codigo distintas, sem sobreposicao.
• Vale conferir se a mensagem de commit reescrita (amend) do commit de LineInfo reflete
  fielmente a intencao original do @lp-parser-llm — o escopo foi reduzido, nao a autoria.

🤖 Generated with Claude Code

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[elson-vinicius-lopes]

Atualização — 4 commits novos desde a criação do PR

Trabalho adicional de 3 agentes em cima da branch, agora pushado:

1. Documentação (abea2b5, @LP-Doc) — README + XML docs cobrindo o contrato aditivo de linha/progresso/degradação.
2. Exposição de lineInfos no payload (3ffe2ec, @lp-backend-dev) — ParseController.Upload agora retorna result.LineInfos (campo lineInfos) no JSON de resposta, permitindo o front consumir os sinais aditivos direto.
3. Cobertura de teste + achado de bug real (ecaf031, @lp-qa) — quality gate PASS, testes novos LineInfoAdditiveSignalsTests.cs e LowCodeTransformationStoreTests.cs. Durante a validação, o QA identificou que IsDeclaredEmpty era inalcançável na prática (comparava a linha bruta inteira em vez dos campos de dado, então praticamente nunca dava true em cenários reais).
4. Fix do bug encontrado pelo QA (07ce492, @lp-parser-llm) — IsDeclaredEmpty corrigido para comparar campos de dado em vez da linha bruta; testes do QA ajustados para refletir o comportamento correto.

Estado final

• dotnet build: 0 erros (625 warnings pré-existentes, nenhum novo relevante).
• dotnet test: 385/389 passando — as 4 falhas são pré-existentes e não relacionadas (diferenças de path Windows×Linux em LowCodeRunnerArgsTests e SafePathResolverTests, ambiente WSL).
• Push feito sem force (fast-forward 0d2a05a..07ce492), sem conflito com o remoto.

Tecnicamente completo e pronto para revisão humana. Aguardando aprovação do dono para merge — não farei merge por conta própria.

[elson-vinicius-lopes]

⚠️ CI falhando após o push — gate de SecurityCodeScan bloqueou

build e build-and-test falharam no step "Security Code Scan - gate por severidade" (não são falhas de compilação/teste — dotnet build/dotnet test locais passaram limpos, ver comentário anterior).

O gate detectou 2 achados NOVOS de severidade ALTA (SCS0018 — path injection) fora do baseline, introduzidos pelos commits mais recentes:

• Controllers/ParseController.cs:550
• Services/Transformation/LowCode/LowCodeTransformationStore.cs:286

Ambos os checks (dependency-review, gitleaks-scan) continuam passando — só o gate de SCS bloqueou.

Numa checagem rápida do código (sem alterar nada — análise de código de produção não é escopo do @lp-devops):

• ParseController.cs:550 já usa SafePathResolver.IsInsideBase(layoutDirectory, filePath) antes de gravar o arquivo — parece falso-positivo do analisador (não enxerga a validação anterior).
• LowCodeTransformationStore.cs:286 lê caminhoIndice, que não parece vir de input externo direto neste trecho — precisa de olhar mais fundo em quem monta esse caminho.

Isso precisa ir para @lp-backend-dev (ou @lp-parser-llm, quem tocou LowCodeTransformationStore) triar: ou (a) é falso-positivo e ganha uma entrada em security-code-scan-baseline.json com justificativa, ou (b) é achado real e precisa de correção (ex.: sanitização explícita antes do File.Exists/File.ReadAllTextAsync). Não vou merge nem vou tocar no baseline sem essa triagem.

PR segue NÃO pronto para merge até o CI ficar verde.