… follow-on)

Closes the remaining safety gap from #111: when a prior run left a package
in PackageState::Ambiguous (reconciliation was inconclusive at that time),
a subsequent `shipper resume` previously fell through to blind cargo retry.
That risked re-uploading a crate whose original upload may have actually
succeeded.

## What this adds

Both the sequential (engine::mod) and parallel (engine::parallel::publish)
publish paths now detect `PackageState::Ambiguous` BEFORE any cargo
activity and reconcile against registry truth first.

Outcomes follow the same state machine as in-flight reconciliation:

- **Published** → mark Published, skip any further cargo work for this
  crate, continue/return success receipt with no republish.
- **NotPublished** → clear Ambiguous back to Pending (registry confirms
  no prior upload), fall through to the normal publish flow.
- **StillUnknown** → emit PublishFailed webhook + halt with an
  operator-actionable error; do NOT retry.

## Parallel + sequential symmetry

- Sequential: new `sequential_reconcile` helper in engine::mod wraps the
  full `RegistryClient::is_version_visible_with_backoff` and returns the
  same `(ReconciliationOutcome, Vec<ReadinessEvidence>)` shape as the
  parallel path's helper. Called from the per-package state-check match
  arm.
- Parallel: reuses existing `reconcile_ambiguous_upload` from
  engine::parallel::reconcile. Called just before the retry-loop entry,
  returning a completed PackageResult early on Published or StillUnknown.

Both paths emit `PublishReconciling` and `PublishReconciled` events so
the event stream records the resume-time reconciliation alongside any
in-flight reconciliation from earlier runs.

## Test plan

- [x] `cargo clippy --all-targets -- -D warnings` clean
- [x] `cargo fmt --check` clean
- [x] 192 engine tests pass (no regressions)

BDD scenarios for resume-path reconciliation across all three outcomes
are a natural follow-up; the handler shape mirrors the in-flight path so
regressions here surface through existing integration tests that already
cover the outcome shape.

## Related

- Parent: #99 Reconcile (the biggest non-cosmetic safety gap from the
  v0.3.0-rc.1 retrospective)
- Sibling PRs already merged: #111 (in-flight reconcile), #112 (events-
  as-truth), #113 (retry narration), #114 (registry-aware backoff)
- Master roadmap: #109

… follow-on) (#115)

Closes the remaining safety gap from #111: when a prior run left a package
in PackageState::Ambiguous (reconciliation was inconclusive at that time),
a subsequent `shipper resume` previously fell through to blind cargo retry.
That risked re-uploading a crate whose original upload may have actually
succeeded.

## What this adds

Both the sequential (engine::mod) and parallel (engine::parallel::publish)
publish paths now detect `PackageState::Ambiguous` BEFORE any cargo
activity and reconcile against registry truth first.

Outcomes follow the same state machine as in-flight reconciliation:

- **Published** → mark Published, skip any further cargo work for this
  crate, continue/return success receipt with no republish.
- **NotPublished** → clear Ambiguous back to Pending (registry confirms
  no prior upload), fall through to the normal publish flow.
- **StillUnknown** → emit PublishFailed webhook + halt with an
  operator-actionable error; do NOT retry.

## Parallel + sequential symmetry

- Sequential: new `sequential_reconcile` helper in engine::mod wraps the
  full `RegistryClient::is_version_visible_with_backoff` and returns the
  same `(ReconciliationOutcome, Vec<ReadinessEvidence>)` shape as the
  parallel path's helper. Called from the per-package state-check match
  arm.
- Parallel: reuses existing `reconcile_ambiguous_upload` from
  engine::parallel::reconcile. Called just before the retry-loop entry,
  returning a completed PackageResult early on Published or StillUnknown.

Both paths emit `PublishReconciling` and `PublishReconciled` events so
the event stream records the resume-time reconciliation alongside any
in-flight reconciliation from earlier runs.

## Test plan

- [x] `cargo clippy --all-targets -- -D warnings` clean
- [x] `cargo fmt --check` clean
- [x] 192 engine tests pass (no regressions)

BDD scenarios for resume-path reconciliation across all three outcomes
are a natural follow-up; the handler shape mirrors the in-flight path so
regressions here surface through existing integration tests that already
cover the outcome shape.

## Related

- Parent: #99 Reconcile (the biggest non-cosmetic safety gap from the
  v0.3.0-rc.1 retrospective)
- Sibling PRs already merged: #111 (in-flight reconcile), #112 (events-
  as-truth), #113 (retry narration), #114 (registry-aware backoff)
- Master roadmap: #109

Implements PR 1 from the scout's plan on issue #103. Wires the existing
RetryBackoffStarted event (landed in PR #113) to a live CLI countdown
in the publish progress reporter, lifting the previously dead
`ProgressReporter::set_status` function and replacing the silent
`thread::sleep(delay)` window with per-second narration in TTY mode.

## What changed

- `engine::Reporter` (and the parallel `Reporter` mirror) gain a new
  `retry_wait(name, version, attempt, max_attempts, delay, reason, msg)`
  default method. The default impl preserves the pre-#103 behavior
  (single `warn()` line + `thread::sleep(delay)`), so every existing
  reporter implementation continues to behave exactly as before.
- The two retry-backoff helpers (`engine::emit_retry_backoff_event` and
  `engine::parallel::publish::emit_retry_backoff`) now record the
  `RetryBackoffStarted` event and then delegate the human-facing
  message + the backoff sleep to `Reporter::retry_wait`. The events.jsonl
  schema is unchanged.
- `ProgressReporter::set_status` is lifted off `#[allow(dead_code)]`.
- New `ProgressReporter::retry_countdown(...)` renders:
  - **TTY:** `[1/N] retrying name@ver in 45s... (attempt 2/5, reason: Retryable) - <msg>`
    refreshed once per second via `set_status` until the wait expires.
  - **Non-TTY (CI):** a single `[retry] name@ver: msg (Retryable); next attempt in 45s (attempt 2/5)`
    line via `eprintln!`, then `thread::sleep(delay)` — no per-second
    spam in pipeline logs.
  - **Quiet:** silent, but still blocks for the full delay.
- `CliReporter` grows an optional `progress: Option<ProgressReporter>`
  field. The `publish` and `resume` subcommands install the existing
  per-registry `ProgressReporter` on the reporter before the engine
  call (and `take_progress().finish()` after), so the engine's
  retry-narration path drives the live countdown.
- `CliReporter::retry_wait` overrides the trait default to route
  through the installed progress, with a graceful fallback to the
  warn-line behavior for callers without a progress bar (e.g. tests).

## Acceptance criteria from the scout's plan

- [x] When `RetryBackoffStarted` is emitted, operator sees:
      - TTY: countdown line ticking down once per second
      - Non-TTY: one-shot `[retry] ...` line then sleep
- [x] Event is still emitted to events.jsonl; no event-schema changes
- [x] `ProgressReporter::set_status` is no longer dead code
- [x] Existing reporter implementations (TestReporter, CollectingReporter,
      SendReporter) continue to compile and behave the same via the
      default trait impl

## Tests

- `progress::tests`: 4 new cases — silent-mode blocks for delay, zero
  delay returns immediately, non-TTY one-shot line drives the !is_tty
  branch, exotic attempt/max boundaries don't panic.
- `lib::tests`: 3 new cases — `CliReporter::retry_wait` without progress
  blocks for delay, with progress routes through countdown, default
  trait impl preserves the canonical warn-line format.
- All 113 `shipper-cli` lib tests pass; all 22 `cli_e2e` integration
  tests pass; all 1890 `shipper-core` tests pass; all 39 `shipper`
  facade tests pass.

* feat(narrate): live CLI countdown during retry/backoff waits (#103 PR 1)

Implements PR 1 from the scout's plan on issue #103. Wires the existing
RetryBackoffStarted event (landed in PR #113) to a live CLI countdown
in the publish progress reporter, lifting the previously dead
`ProgressReporter::set_status` function and replacing the silent
`thread::sleep(delay)` window with per-second narration in TTY mode.

## What changed

- `engine::Reporter` (and the parallel `Reporter` mirror) gain a new
  `retry_wait(name, version, attempt, max_attempts, delay, reason, msg)`
  default method. The default impl preserves the pre-#103 behavior
  (single `warn()` line + `thread::sleep(delay)`), so every existing
  reporter implementation continues to behave exactly as before.
- The two retry-backoff helpers (`engine::emit_retry_backoff_event` and
  `engine::parallel::publish::emit_retry_backoff`) now record the
  `RetryBackoffStarted` event and then delegate the human-facing
  message + the backoff sleep to `Reporter::retry_wait`. The events.jsonl
  schema is unchanged.
- `ProgressReporter::set_status` is lifted off `#[allow(dead_code)]`.
- New `ProgressReporter::retry_countdown(...)` renders:
  - **TTY:** `[1/N] retrying name@ver in 45s... (attempt 2/5, reason: Retryable) - <msg>`
    refreshed once per second via `set_status` until the wait expires.
  - **Non-TTY (CI):** a single `[retry] name@ver: msg (Retryable); next attempt in 45s (attempt 2/5)`
    line via `eprintln!`, then `thread::sleep(delay)` — no per-second
    spam in pipeline logs.
  - **Quiet:** silent, but still blocks for the full delay.
- `CliReporter` grows an optional `progress: Option<ProgressReporter>`
  field. The `publish` and `resume` subcommands install the existing
  per-registry `ProgressReporter` on the reporter before the engine
  call (and `take_progress().finish()` after), so the engine's
  retry-narration path drives the live countdown.
- `CliReporter::retry_wait` overrides the trait default to route
  through the installed progress, with a graceful fallback to the
  warn-line behavior for callers without a progress bar (e.g. tests).

## Acceptance criteria from the scout's plan

- [x] When `RetryBackoffStarted` is emitted, operator sees:
      - TTY: countdown line ticking down once per second
      - Non-TTY: one-shot `[retry] ...` line then sleep
- [x] Event is still emitted to events.jsonl; no event-schema changes
- [x] `ProgressReporter::set_status` is no longer dead code
- [x] Existing reporter implementations (TestReporter, CollectingReporter,
      SendReporter) continue to compile and behave the same via the
      default trait impl

## Tests

- `progress::tests`: 4 new cases — silent-mode blocks for delay, zero
  delay returns immediately, non-TTY one-shot line drives the !is_tty
  branch, exotic attempt/max boundaries don't panic.
- `lib::tests`: 3 new cases — `CliReporter::retry_wait` without progress
  blocks for delay, with progress routes through countdown, default
  trait impl preserves the canonical warn-line format.
- All 113 `shipper-cli` lib tests pass; all 22 `cli_e2e` integration
  tests pass; all 1890 `shipper-core` tests pass; all 39 `shipper`
  facade tests pass.

* fix(parallel): release reporter lock before retry sleep

* fix(narrate): restore live retry feedback in parallel mode