fix(entries): preservar status agendado e adicionar --scope no update

[fm1randa]

Refs #65

O que muda

• Status preservado: um lançamento agendado continua agendado ao ser editado. O PUT vai com status: { confirmado: false, conciliado: false } e sem preencher dataEfetiva/valorEfetivo (manda só o que o lançamento já tinha, normalmente nada). Antes ia sempre confirmado: true com data/valor efetivos, o que confirmava a ocorrência e tirava ela da série. O status só muda com flag explícita: --pending (confirma sem conciliar) ou --reconciled. O mesmo vale para transferências agendadas (não manda dataEfetiva/valorEfetivo/valorEfetivoT).
• --scope this|following (padrão this): vira todos: false|true no corpo do PUT. É o "Apenas neste" / "Neste e em todos na sequência" da web (lanc.todos = (alteracao == 2) no js/md.js). Pelo teste real do Filipe, todos: true altera esta ocorrência e as seguintes, e o servidor divide a série. todos só vai para ocorrências de série (agendaId + parcela, mesma regra da web). Fora de série, --scope following dá erro antes do PUT. Valor inválido é rejeitado pelo Commander.
• Aviso no stderr: ao editar uma ocorrência de série sem --scope, sai no stderr um aviso de que só esta ocorrência será alterada e sairá da série. O stdout do --json continua JSON válido.
• Status real: o resumo imprime o status que a API devolveu (conciliado/pendente/agendado, ou o objeto {confirmado, conciliado}), e não mais "Scheduled" como fallback fixo. Para série, imprime também o escopo.
• Igual ao patch local testado pelo Filipe: ao mover a data de uma ocorrência agendada, agenda.primeiraData acompanha a nova data.

Testes

• test/entries-update-series.test.ts (7 testes) confere o payload que chegou ao mock com literais: status, ausência de dataEfetiva/valorEfetivo, todos, agenda.primeiraData, --pending confirmando, transferência agendada, entrada fora de série e --scope inválido. Confere também o aviso no stderr e o status impresso.
• Mock do verify (scripts/mock-api.ts): nova ocorrência agendada 80 (NuCel, fixa). O PUT deriva o status do objeto enviado e, como a API real, trata dataEfetiva preenchida como confirmação. A ocorrência só fica na série com todos: true, e todos em lançamento fora de série dá 400. Os seeds foram para scripts/mock-entries.ts por causa do max-lines.
• verify.sh ganha 6 passos E2E: agendado mantém status, aviso no stderr, --scope following em JSON e texto, --pending confirma e --scope fora de série falha.

Verificação

scripts/verify.sh local → VERIFICAÇÃO OK (127 testes, exit 0). Nada foi testado contra a API real.