fix(attachments): make --replace work on Data Center/Server

[bestend]

Problem

confluence attachment-upload <pageId> --file a.html --replace fails on Confluence Data Center/Server with Request failed with status code 405.

--replace sends PUT /rest/api/content/{pageId}/child/attachment. That "create or update attachment" endpoint exists in the Confluence Cloud v1 API, but the Data Center REST API has no PUT on the attachment collection: it offers POST .../child/attachment (create only) and POST .../child/attachment/{attachmentId}/data (replace the data of an existing attachment). On Data Center, a filename that already exists can therefore be neither uploaded again (400) nor replaced (405).

Observed on Confluence Data Center 9.2.9 (PAT bearer auth, apiPath /rest/api):

Request	Result
attachment-upload <pageId> --file a.html	OK, new attachment
same file again, without --replace	HTTP 400 Cannot add a new attachment with same file name as an existing attachment: a.html
same file again, with --replace	Request failed with status code 405
POST /rest/api/content/{pageId}/child/attachment/{attachmentId}/data (multipart file, header X-Atlassian-Token: nocheck, optional minorEdit/comment)	HTTP 200, attachment version incremented, content replaced

Fix

On Data Center/Server (!isCloud()), --replace now looks the attachment up by exact filename (GET .../child/attachment?filename=<name>) and POSTs the file to .../child/attachment/{attachmentId}/data. When the page has no attachment with that name, it does the regular create POST. comment and minorEdit are sent as before.

• Cloud (*.atlassian.net, forceCloud, scoped tokens) keeps the existing PUT, which is an atomic create-or-update, so its behavior and request count are unchanged.
• Only an exact title match selects the target, so a server that ignores the filename filter cannot make the CLI overwrite another attachment.
• POST .../{attachmentId}/data answers with the updated attachment itself (a single object with type: "attachment") on Data Center 9.2.9, as the Cloud reference documents, while older Data Center references show { results: [...] }. uploadAttachment accepts both, so results (and the ID/Version output of the command) stays uniform.
• The attachment ID is URL-encoded before it goes into the path.
• README and SKILL.md now state the --replace semantics.

Verification

• Added 13 unit tests using the existing axios-mock-adapter approach: Data Center replace through POST .../{id}/data (headers, multipart body, comment/minorEdit), create when nothing matches, exact-title selection, special characters in the filename, ID encoding, single-object and { results } responses, failed lookup, no lookup without --replace, and Cloud unchanged for *.atlassian.net, forceCloud and scoped tokens. 9 of them fail on main with the 405 above; the other 4 guard the unchanged paths.
• npm test: 1466 passed (1453 before). npm run lint: clean.
• Ran this branch against the Confluence Data Center 9.2.9 server on a throwaway page: v2.25.8 still answers --replace with 405; this branch replaced the attachment twice under the same attachment ID (version 1 → 2 → 3, --comment included), the downloaded file matched the last upload, and --replace with a new filename created a new attachment.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Testing

• Tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

🤖 Generated with Claude Code

[pchuri]

Thanks for the detailed report, implementation, and Data Center reproduction. The split between the Cloud PUT path and the Data Center/Server lookup-and-POST path looks appropriate, and the exact filename check and response normalization are well covered.

I reviewed the current head and ran the client test suite (269/269 passing) and lint successfully. I did not find a blocking issue in the reviewed changes. I have not independently repeated the live Confluence checks or run the full repository test suite yet, but this looks ready to move toward merge after that final validation. Thanks for the contribution!

[github-actions]

🎉 This PR is included in version 2.25.9 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀