feat(retrieval): parallel IPNI + transport with retrievalTransportStatus counter

[SgtPooki]

What changed

In pgBoss mode, `performAllRetrievals` gated the `/ipfs` transport on IPNI verification: any IPNI lag bypassed the transport path entirely and pinned `retrievalStatus=failure.*`. Combined with the silent-timeout bug (#524), the failure mode was invisible in logs.

This PR runs IPNI and transport concurrently and composes the terminal status as `AND(discoverabilityStatus, retrievalTransportStatus)`. A new `retrievalTransportStatus` counter records the `/ipfs`-only outcome so a single dashboard panel can attribute a `retrievalStatus` failure to IPNI vs transport.

Implements option A from #524. Matches the parallel flow already documented in `docs/checks/retrievals.md`.

Files

• `apps/backend/src/retrieval/retrieval.service.ts` — parallel orchestration via `Promise.allSettled`, classify + compose helpers.
• `apps/backend/src/metrics-prometheus/{metrics-prometheus.module.ts,check-metrics.service.ts}` — register `retrievalTransportStatus` counter and `recordTransportStatus` method.
• `docs/checks/{events-and-metrics.md,retrievals.md}` — document the new counter and the composite-status rule.
• `apps/backend/src/retrieval/retrieval.service.spec.ts` — 4 new tests covering IPNI+transport success, IPNI fail / transport success, IPNI timeout / transport success, and concurrent execution ordering.

How to verify

```
pnpm --filter dealbot-backend typecheck
pnpm --filter dealbot-backend lint
pnpm --filter dealbot-backend test
```

After deploy, watch:

• `retrievalTransportStatus{value=success}` should equal `/ipfs` success volume per SP.
• For approved SPs with high `retrievalStatus=failure.*` but high `retrievalTransportStatus=success`, the failure is in IPNI discoverability, not transport.

Notes

`retrievalStatus` semantics unchanged (AND of discoverability and transport). No dashboard migration needed; the new `retrievalTransportStatus` chart is opt-in.

Observability follow-ups for the silent-timeout cases (the catch-order bug in `ipni-verification.service.ts` and the missing `retrieval_skipped_ipni_failure` log) ship as a separate PR (option C from #524) on top of this one.

[Copilot]

Pull request overview

This PR updates the backend Retrieval check to run IPNI verification and /ipfs transport in parallel, and introduces a new Prometheus counter (retrievalTransportStatus) to separately attribute failures to transport vs discoverability while keeping retrievalStatus as the composite (AND) outcome.

Changes:

• Parallelize IPNI + transport execution in RetrievalService using Promise.allSettled, then classify and compose terminal status from both sub-statuses.
• Add and register the retrievalTransportStatus Prometheus counter and expose a recordTransportStatus helper on RetrievalCheckMetrics.
• Update retrieval/check docs and add tests covering combined outcomes plus a concurrency-ordering test.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
docs/checks/retrievals.md	Documents parallel IPNI + transport flow and clarifies composite retrievalStatus semantics.
docs/checks/events-and-metrics.md	Defines the new retrievalTransportStatus metric and documents the composite rule for retrievalStatus.
apps/backend/src/retrieval/retrieval.service.ts	Runs IPNI + transport concurrently; records retrievalTransportStatus; composes terminal retrievalStatus.
apps/backend/src/retrieval/retrieval.service.spec.ts	Adds pgBoss-mode tests for combined IPNI/transport outcomes and a concurrency assertion.
apps/backend/src/metrics-prometheus/metrics-prometheus.module.ts	Registers the new retrievalTransportStatus counter provider.
apps/backend/src/metrics-prometheus/check-metrics.service.ts	Injects the new counter and adds recordTransportStatus.

[BigLep]

Requesting changes to get aligned on what counters are emitted and when.

[silent-cipher]

code portion looks good overall. Just one comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

apps/backend/src/retrieval/retrieval.service.spec.ts:506

• Blocker: Similar to the previous case, this test expects retrievalStatus=success when IPNI times out. If retrievalStatus is the composite retrieval outcome (as documented), an IPNI timeout should make retrievalStatus a failure (with a separate transport-only metric tracking /ipfs success).

  it("keeps retrievalStatus=success when IPNI times out but transport succeeds (timeout recorded on discoverabilityStatus)", async () => {
    service = await createService();
    setupCommonMocks();
    mockIpniVerificationService.verify.mockResolvedValue({
      verified: 0,
      unverified: 1,
      total: 1,
      rootCIDVerified: false,
      durationMs: 10_000,
      failedCIDs: [{ cid: "x", reason: "timeout" }],
      verifiedAt: new Date().toISOString(),
    });
    mockRetrievalAddonsService.testAllRetrievalMethods.mockResolvedValue(successfulTransport);

    await service.performAllRetrievals(buildDealWithIpni());

    expect(mockRetrievalMetrics.recordStatus).toHaveBeenCalledWith(labels, "success");
    expect(mockDiscoverabilityMetrics.recordStatus).toHaveBeenCalledWith(labels, "failure.timedout");
  });

[BigLep]

One comment to review, but looks good to me from a docs regard. I'll leave to @silent-cipher to give the code approval.

[silent-cipher]

LGTM!

already addressed.