jira: support Jira Cloud (API token via Basic auth) alongside Server PAT

[atomantic]

What

PortOS's JIRA client authenticated every instance with Authorization: Bearer <apiToken> — correct for a Jira Server / Data Center Personal Access Token, but Jira Cloud rejects it: a Cloud personal API token must be sent as HTTP Basic (base64("email:token")).

createJiraClient now picks the scheme per instance by host:

• *.atlassian.net (Jira Cloud) → Basic using the instance's email + API token (both already stored and required by the instance form)
• any other host → Bearer PAT (unchanged)

So Cloud and Server instances work side by side with no new fields and no migration. To point an instance at Cloud, set its base URL to your *.atlassian.net site and paste an API token created at id.atlassian.com → Security → API tokens.

How

• New pure helpers in server/services/jira.js: isCloudInstance(baseUrl) (delegates host parsing to the shared no-throw hostFromOriginUrl from server/lib/workTracker.js) and jiraAuthHeader(instance).
• createJiraClient uses jiraAuthHeader(instance) for the Authorization header.
• Expired-token message updated to name both credential types.

Tests

server/services/jira.test.js — added coverage for both auth paths plus edge cases (undefined/malformed URL, :port, lookalike atlassian.net.evil.com). 14/14 pass.

Known limitation (by design)

Detection keys strictly on *.atlassian.net. A Jira Cloud site fronted by Atlassian's custom-domain feature (e.g. jira.mycompany.com → Cloud) is classified as Server and gets Bearer. Out of scope here; a per-instance authScheme override could be added later if needed.

Related

• Deferred follow-up filed as JIRA: make expired-token detection Cloud-aware (checkToken assumes Server HTML login page) #2235 (make checkToken expiry detection Cloud-aware — Cloud returns JSON 401, not an HTML login page).