fix(miner): attempt-cli.js mislabels own-rejection-history aborts as ai_usage_policy_ban

[JSONbored]

Context

packages/loopover-miner/lib/rejection-signal.js's own module header documents that resolveRejectionSignaled resolves two triggers as of #5655: (1) an explicit AI-usage-policy ban on the target repo, and (2) a prior submission from this same miner that was closed/rejected on this exact repo (resolveOwnRejectionHistory). The header explicitly says this closed the gap it used to document, and rejectionSignaled now returns true if either trigger fires.

packages/loopover-miner/lib/attempt-cli.js was not updated to match. Its inline comment still says the second trigger "remains a documented gap," and its code unconditionally does:

if (rejectionSignaled) {
  const reason = "ai_usage_policy_ban";
  // ... appendAttemptLogEvent({ eventType: "attempt_aborted", ... reason ... })

So when rejectionSignaled is true because of the second trigger (a prior own-submission rejection, not a policy ban), the emitted attempt_aborted/attempt_blocked audit-trail event and the CLI's --json output both mislabel the reason as ai_usage_policy_ban — a real correctness bug in the audit trail, not just a stale comment. test/unit/miner-attempt-cli.test.ts locks in the wrong label today by asserting reason: "ai_usage_policy_ban" for a generically-mocked resolveRejectionSignaled returning true regardless of which trigger fired.

Requirements

• resolveRejectionSignaled (or the resolver it delegates to) must report which trigger fired, not just a boolean — read rejection-signal.js directly to find the least-invasive way to surface this (it may already compute this internally and just not return it).
• attempt-cli.js's reason value must reflect the actual trigger: "ai_usage_policy_ban" for the first trigger, a distinct, accurately-named reason (e.g. "own_submission_rejected" — pick a name consistent with this codebase's existing attempt_aborted/attempt_blocked reason-string conventions, don't invent an inconsistent style) for the second.
• Update the stale inline comment in attempt-cli.js that says the second trigger "remains a documented gap" — it does not, per rejection-signal.js's own header.
• Do not change resolveRejectionSignaled's existing boolean short-circuit behavior for callers that only need the boolean (e.g. iterate-policy.ts, if it consumes this) — this is an additive change to the trigger-source signal, not a breaking API change.

Deliverables

• rejection-signal.js (or its resolver) surfaces which trigger fired
• attempt-cli.js uses the accurate, trigger-specific reason string in both the audit-trail event and --json output
• Stale "remains a documented gap" comment in attempt-cli.js corrected
• test/unit/miner-attempt-cli.test.ts updated/extended to assert the correct reason for each trigger separately (the existing test currently only proves the wrong-but-passing behavior for the second-trigger case)

Test Coverage Requirements

99%+ patch coverage (branch-counted), including both trigger-source branches.

Expected Outcome

An attempt_aborted/attempt_blocked event (and matching --json CLI output) correctly distinguishes "this repo has an AI-usage-policy ban" from "this miner was previously rejected on this repo" — the audit trail is accurate for both trigger sources.

Links & Resources

• packages/loopover-miner/lib/attempt-cli.js (the mislabeling site, rejectionSignaled handling)
• packages/loopover-miner/lib/rejection-signal.js (module header documenting both triggers, #5655)
• test/unit/miner-attempt-cli.test.ts (test locking in the current wrong label)
• packages/loopover-engine/src/miner/iterate-policy.ts (the doc comment rejectionSignaled's contract is meant to satisfy)

[linear-code]

JSO-4147