[Feature] Return machine-readable arguments and retry timing for job follow-ups

[morluto]

Problem

GitContribute exposes more actionable recovery information in some item-level batch results than it exposes for asynchronous jobs. Item results can carry suggested tool arguments and retry_after_ms, while JobFollowUp currently carries only the next tool, resource URI, and a reason. A caller therefore has to reconstruct arguments or guess when to retry after polling a job.

The coverage half of this problem is tracked by the open #233. This issue covers the missing job-side contract.

Proposed outcome

Use one machine-readable recovery shape across batch items and job results:

{
  "tool": "jobs.get",
  "arguments": {"id": "job-id"},
  "reason": "The job is still running; poll its durable result.",
  "retry_after_ms": 1000
}

Resource URIs and other handoff fields may remain alongside this object, but the recovery action must preserve the exact advertised tool and arguments rather than only a prose instruction.

Acceptance criteria

• Queued and running jobs return the exact polling tool and arguments.
• Completed jobs return exact follow-up arguments for artifact/resource reads.
• Retryable failures include a non-negative retry_after_ms when a delay is known.
• Batch item actions and job follow-ups use the same field names and semantics.
• Existing offline/no-implicit-network behavior remains unchanged.
• Tests cover polling, sync-job handoffs, index-job handoffs, and retryable failures.

Please coordinate the final shape with #233 rather than duplicating its coverage-specific report.

[morluto]

Fixed by the merged follow-up contract redesign in #247. Job follow-ups now use discriminated actions with typed arguments and retry timing.