jira_service_desk: add attachment write tools (#21869)

* jira_service_desk: add attachment write tools

Extends `create-request` with optional file attachments at creation time,
and adds a new `manage-request-attachment` tool to add, replace, or delete
attachments on an existing request. Delete uses the Jira Platform API since
JSM has no equivalent endpoint.

Closes #21850, closes #21851

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* jira_service_desk: fix form-data lockfile specifier

The monorepo's pnpm override pins form-data@^4 to 4.0.4, so the lockfile
specifier must match the override target (no caret) rather than the
literal range in package.json.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* jira_service_desk: bump component versions per PR review

Corrects create-request's version and bumps every other action/source in
the package to keep them in lockstep with the package.json minor bump.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* jira_service_desk: correct create-request version to 1.0.3

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* jira_service_desk: address review findings on attachment tools

- create-request: bump to 1.1.0 (backward-compatible attachments/
  attachmentsPublic addition); return the attachments array itself
  instead of the whole attach-response envelope
- manage-request-attachment: verify attachmentId actually belongs to
  issueIdOrKey before any delete, on both the delete and update paths;
  reorder update (replace) to upload-then-delete so a failed upload
  never leaves the request with no attachment at all
- app file: upload each file as its own request instead of buffering
  every file into one shared FormData first, so only the small
  temporaryAttachmentId is retained across iterations

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* jira_service_desk: surface delete failures in manage-request-attachment

If the new attachment succeeds during an update (replace) but removing
the old attachment then fails, return a deleteError alongside the
successful attach response instead of letting the raw delete error
propagate and mask that the new file was already added.

Skipped a related nit: getIssueAttachments derives attachment id from
_links.jiraRest, which Atlassian's docs confirm is always present on
this DTO. The same optional-chaining is pre-existing, shared code also
used by list-issue-attachments and download-issue-attachment, so
fixing it only for this new call site would be inconsistent, and the
failure mode already fails safe (blocks the operation) rather than
proceeding incorrectly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* add ai: "optimized"

* jira_service_desk: fix attachmentId description, add/update response has no plain id field

Reviewer noted the id is only embedded in a _links.jiraRest URL under
attachments.values[], not returned directly. Point to List Issue
Attachments instead, which already extracts the flat id.

* jira_service_desk: bump component versions

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>