Two fault-discipline residuals, both in the legacy provider, both about a
report that ships incomplete and still exits 0.

Fixes #386
Fixes #388

The shape both fixes land on

The project already reports attachment degradation in two places: the export
call site names the cause, and Summary.validate() names the symptom
it can see in the assembled model. These changes make logs work the same way
and make the legacy payload path actually reach its call site:

#386 — a log that vanishes must not exit 0

ResultFile.exportLogs/exportLogsData already record .logExportFailed
(that landed in #443), and --json no longer swallows an empty report (#451).
What never landed is the issue's third ask: extend validate() to cover log
content. Without it, a legacy actionResult.logRef that exists in the bundle
but fails to decode arrives as nil (LegacyResultReader.swift:49), Run.init
warns and sets logContent = .none, and the report ships log-less at exit 0.

Placement: validate(), not the read path. The issue asks for it there, and
it is the only place that can see this class of failure:

• The motivating failure has no call site to record at. XCResultKit decodes
  actionResult.logRef tolerantly, so a broken reference and an absent one are
  the same nil by the time the reader sees them. Telling them apart would mean
  re-reading the raw invocation-record JSON, and XCResultKit keeps that internal
  (getRootJson is not public at the pinned 1.2.2).
• A post-condition is backend-neutral by construction: one rule over the
  assembled model, rather than two providers that have to keep agreeing.
• It is exactly the rationale already written into validate()'s doc comment
  for attachments — nested decode failures that call-site checks structurally
  cannot see.

The cardinal rule is respected. Run.logFailedToResolve mirrors
Attachment.failedToResolve: a run with no log reference at all is structural
absence and is never a fault; only a reference that existed and produced no
content is. Run now retains logReference for exactly that reason, the same
way Attachment retains payloadId.

Run.logFaultDescription names the run's destination rather than the reference,
because the reference is backend-internal (a CAS id on legacy, a --type
selector on modern) — so the symptom fault reads identically on both backends
for the same broken bundle, while only the cause fault differs.

#388 — the dead guards and the missing catch fault

XCResultFile.exportPayload(id:) returns its temp path unconditionally, so the
guard let savedURL = ... else fault branches at ResultFile.swift:79 and
:119 were unreachable and every real failure surfaced later as the moveItem
throw. Implemented the issue's preferred fix rather than deleting them:

• The guard now also requires the exported file to exist and be non-empty
  (ResultFile.exportProducedPayload). The Optional stays in the condition
  because upstream's signature is URL?, but it is no longer the only thing
  being tested, so the branch is live. A failed export leaves nothing behind,
  and an attachment with no bytes carries no payload reference at all (validate() false-positives on attachments with no payloadRef #387), so
  an empty file is a failed export and not an empty payload.
• exportPayloadData's catch now records .payloadExportFailed, matching its
  modern twin at ModernPayloadStore.swift:94. Before this, a genuine inline
  export failure recorded nothing at the call site.
• exportPayloadData now removes the temp file it read. Unlike the linking
  export, which moves it into the bundle, this one only read it — so every
  inline export left a full copy at NSTemporaryDirectory()/<id>, tens of
  megabytes per run for screen recordings. ModernPayloadStore already cleans
  up for that reason. It also keeps the new check honest: nothing survives to
  satisfy it on a later, failed export of the same id.

The new check also gets the same belt-and-braces the move's catch already had:
if the payload is already sitting at its destination, another exporter of that
id produced it and ours producing nothing is not degradation. Without that,
tightening the guard would have turned #449 back into spurious faults under
concurrent exports of a shared payload ref.

Fault kind. The verification of these issues flagged that the issue's check
changes which kind an inline failure reports. It lands on .payloadExportFailed
at the call site, which is the semantically correct one: this is a payload that
could not be exported, not a model-level observation. .unresolvedAttachment
still fires from validate() for the same attachment, unchanged — cause and
symptom, exactly as the linking path has always behaved. The net effect is that
legacy inline now matches legacy linking and modern inline instead of being the
one path that reported only the symptom.

No README change: the exit-code table is kind-agnostic (0/1/3/64), which is the
condition the issue attached to its note.

Tests

LogFaultReportingTests (#386), new file:

• testRunWithoutLogReferenceIsNotAResolutionFailure — the cardinal rule.
• testRunWhoseLogCannotBeResolvedIsRecordedAsFault — a ParsedRun whose
  reference the (silent) stub provider cannot resolve. It asserts the collector
  is empty before validate(), so what it finds afterwards can only have come
  from the post-condition, not from a call site. Also asserts idempotency.
• testRunWithAResolvableLogIsNotAFault — the over-firing guard.
• testUnreadableLogExitsNonZeroIdenticallyOnBothBackends — end to end. Copies
  SanityResults.xcresult, deletes the CAS object its log reference names, and
  runs the CLI on both readers: each exits 3 and reports
  logExportFailed + unresolvedLog: log for run <device>, the symptom detail
  being byte-identical across backends. That also closes the coverage gap the
  verification of Extend fault reporting to log export and JSON output #386 called out — until now nothing asserted
  .logExportFailed on the modern backend at all.

PayloadExportFaultTests (#388), new file:

• testInlinePayloadExportFailureIsRecordedAsFault — the regression the missing
  catch fault allowed: nil returned, nothing recorded.
• testLinkingPayloadExportFailureIsRecordedOnce — one failed export stays one
  fault now that the guard fires before moveItem.
• testExportedPayloadIsOnlyAcceptedWhenItHasBytes — pins the empty-file arm,
  which no reachable input produces.
• testInlineExportDoesNotLeaveItsTempFileBehind — the stale-temp-file hazard.

Review round

Three CodeRabbit findings, all accepted:

• exportProducedPayload(at:) requires a regular file. A directory reports a
  nonzero size of its own, so the size test alone would have passed one.
• Both "the payload is already at the destination" fallbacks — the new one and
  the long-standing one in the move's catch — now use that predicate instead of
  a bare fileExists. An empty destination was being returned as a successful
  export, which is the same silent hole Dead code: XCResultFile.exportPayload never returns nil #388 is about: the attachment resolves
  to a URL, so validate() sees content and records nothing.
• exportPayloadData registers its temp-file cleanup before the payload check,
  so a half-made file an unsuccessful export left behind is removed too. The
  nil-unwrap and the content check stay in one guard — splitting them to make
  room for the defer would restore the standalone dead branch this PR removes.
• validate() dedups within a single pass as well as across calls, so one
  bundle passed twice yields one entry rather than two the reader cannot tell
  apart. That applies to attachments too; the attachment loop had the same
  snapshot-only behaviour before this PR.

Full suite green on both reader legs, DifferentialTests included: 138 tests,
0 failures on each.