`issue view --output json` omits `duedate`, so a set due date reads as unset

[arcaven]

A due date set through the CLI cannot be read back through the CLI's JSON output. jr issue view KEY --output json omits duedate from .fields, and the standard access pattern (jq .fields.duedate) renders the missing key as null, which is exactly what an unset due date looks like. I verified a successful duedate write this way today and misdiagnosed it as a silent write failure; the value was fine, the read surface was lying by omission.

This looks like the remainder of the class fixed in #59, which added created, updated, and reporter to the view JSON for the same reason: the JSON output is the scripting surface, and fields users act on need to round-trip.

Expected

jr issue view KEY --output json includes duedate in .fields, as it does for the other user-visible system fields (created, updated, resolution, and the rest of the default list).

Actual

.fields has no duedate key at all, set or not. Reading through the raw API works: jr api "/rest/api/3/issue/KEY?fields=duedate" returns the value.

Repro (issue key sanitized; run against a Jira Cloud issue you can edit)

$ jr api -X put /rest/api/3/issue/KEY -d '{"fields":{"duedate":"2027-07-30"}}'
# succeeds (204)

$ jr issue view KEY --output json | jq '{has: (.fields | has("duedate")), value: .fields.duedate}'
{
  "has": false,
  "value": null
}

$ jr api "/rest/api/3/issue/KEY?fields=duedate" | jq -r .fields.duedate
2027-07-30

Mechanism: BASE_ISSUE_FIELDS drives the requested field list for both get_issue and search_issues, and duedate is not in it, so the server never sends the field. That shared list means issue list --output json has the same gap. Relevant paths: src/api/jira/issues.rs (BASE_ISSUE_FIELDS).

Could duedate join BASE_ISSUE_FIELDS, as created, updated, and reporter did in #59? The --fields <CSV> proposal in #575 would give an escape hatch, but a date field settable through the CLI seems worth having in the default read. Happy to follow up with a PR.