issue create: --on-behalf-of silently ignored without --request-type — warn-and-create half-succeeds in batch use

[arcaven]

What happened

Batch-creating service requests on behalf of other users, --on-behalf-of is silently downgraded to a warning when --request-type isn't supplied — the issue is still created, but with the API caller as reporter:

$ jr issue create -p CRAWL -t "[System] Service request" \
    --on-behalf-of 5f9a1b2c3d4e5f0001abcdef \
    -s "Loot dispute: fourth-floor boss box — Princess Donut" \
    --description-stdin --markdown < donut.md
warning: --on-behalf-of is ignored on the platform create path; it only applies with --request-type (JSM service-desk requests). To raise a request on behalf of another user, also supply --request-type.
Created issue CRAWL-1337

In an interactive session the warning is fine. In a loop creating one request per crawler, it scrolls past and you end up with 14 tickets all reported by the automation account instead of Carl, Donut, Katia, et al. — half-success is the worst outcome for a batch: the issues exist (so a re-run duplicates them) but the reporter is wrong on every one.

Why the platform path could honor it anyway

The platform REST API accepts a reporter at create time (fields.reporter.accountId), and it's also editable afterward — this workaround succeeds with the same token:

$ jr api -X put /rest/api/3/issue/CRAWL-1337 \
    -d '{"fields":{"reporter":{"accountId":"5f9a1b2c3d4e5f0001abcdef"}}}'

So the capability doesn't strictly require the JSM raiseOnBehalfOf path — on the platform path, --on-behalf-of could map to fields.reporter (or a separate --reporter flag could, keeping the JSM semantics distinct).

Suggestions (any of these would resolve it)

1. Map --on-behalf-of (or a new --reporter) to fields.reporter.accountId on the platform create path, or
2. Make the current condition a hard error instead of warn-and-create — a batch script would then fail fast instead of half-succeeding, or
3. At minimum, document the create-then-PUT-reporter workaround next to the flag.

Happy to test a build. Version: jr 0.6.0-dev.10, Jira Cloud, company-managed JSM project.

[arcaven]

Split the --reporter half of suggestion 1 out into #673, with a second use case attached: filing a problem report on the platform create path on behalf of the person who reported it, where --on-behalf-of is not in play at all and there is no flag to reach for. That one also shows the create-then-PUT workaround needing an out-of-band accountId lookup even though --to on the same command line already resolves a name.

Leaving this issue as the warn-and-create semantics report, since the two can be fixed independently.