Independent of #4211 (off main, no merge-order dependency).

Summary

Parses the initiator field the Hub returns on jobs API responses. Adds a
JobInitiator dataclass + JobInfo.initiator field. Pure data-layer
addition — no ps table column in this PR.

• _jobs_api.py: new JobInitiator dataclass + new JobInfo.initiator field
• __init__.py: re-export JobInitiator alongside the existing job dataclasses

Variants the Hub returns:

• user / org — ad-hoc runs (name populated)
• scheduled-job — cron-triggered runs (id only)
• duplicated-job — runs created via POST /duplicate (id only)

All share type and id; name is only set for user/org. Matches the
lightweight shape of the existing JobOwner (no avatar_url — keeps
inspect output tight). The server-side avatarUrl is dropped at the
call site rather than absorbed into the dataclass, matching how
JobOwner / JobStatus are constructed in this file.

Why

Useful for both human users (knowing at-a-glance what triggered a job in
inspect output) and agents inspecting a user's job history programmatically.
When scanning many jobs from the same user, initiator is the only way to
disambiguate manual runs from automated/scheduled ones. The data was already
available server-side; the Python library was silently dropping it on parse.

Where it surfaces

Sample output

Two real jobs run by the same user — one ad-hoc, one cron-triggered. Note how
initiator disambiguates them while owner is identical:

$ hf jobs inspect 6a01d697aff1cd33e8f33a64
[
    {
        "id": "6a01d697aff1cd33e8f33a64",
        "status": {"stage": "COMPLETED", "message": null},
        ...
        "owner": {"id": "60107b385ac3e86b3ea4fc34", "name": "davanstrien", "type": "user"},
        "initiator": {"type": "user", "id": "60107b385ac3e86b3ea4fc34", "name": "davanstrien"}
        ...
    }
]

$ hf jobs inspect 6a01c8c2aff1cd33e8f339d4
[
    {
        "id": "6a01c8c2aff1cd33e8f339d4",
        "status": {"stage": "COMPLETED", "message": null},
        ...
        "owner": {"id": "60107b385ac3e86b3ea4fc34", "name": "davanstrien", "type": "user"},
        "initiator": {"type": "scheduled-job", "id": "69c4179671691dc46f166314", "name": null}
        ...
    }
]

For cron-triggered runs, initiator.type == "scheduled-job" and
initiator.id points at the schedule definition. Agents can filter the full
list directly off --format json:

$ hf jobs ps -a --format json | jq '[.[] | select(.initiator.type == "scheduled-job")] | length'
63

Open question for reviewers

Should we add an INITIATOR column to the default hf jobs ps table?

• For: glance-scan UX — "which of these are cron vs manual?"
• Against: column-count creep — ps is already 5 cols (6 if [CLI] Surface job runtime fields in ps + inspect #4211 lands),
  150+ chars wide on standard terminals
• Adjacent UX problem: active runs buried under historical ERROR/COMPLETED
  rows — better addressed by a --sort status flag or --active-only shortcut

Kept this PR minimal so the display decision can have its own discussion.

Test plan

• Parametrized parse tests for all four variants (user / org / scheduled-job / duplicated-job)
• Default-None test (when initiator field absent)
• Smoke-tested locally against real jobs — user and scheduled-job initiators both parse; server-side avatarUrl extra is silently filtered

🤖 Generated with Claude Code