fix(sdk): tag raising S3 PUT failures with the s3_upload step

[mocha06]

Motivation

AttachmentService's docstring promises every step surfaces as AttachmentUploadError carrying step, but the S3 put call was not wrapped: an httpx transport error or the uploader's host-allowlist ValueError bubbled bare instead of being tagged step="s3_upload". Only HTTP >= 400 results from a completed PUT were tagged, so the step-aware error envelope silently degraded to a generic untagged error for exactly the network / tampered-URL failures where the stage tag is most useful.

Outcome

Transport errors and host-allowlist rejections from the S3 PUT now raise AttachmentUploadError(step="s3_upload") from the cause, keeping the attachment and knowledge-base document upload pipelines on one contract. Existing HTTP >= 400 tagging is unchanged.

Closes #430

[adriannoes]

Summary

Surgical fix that closes #430: raising S3 PUT failures now surface as AttachmentUploadError with step="s3_upload", matching the KnowledgeBaseService wrap. Reviewed with checkout+tests; CI lint and test are green on the tip.

What worked well

• Mirrors the KB put wrap from #428 so attachment and knowledge-base uploads stay on one contract.
• Unit test asserts step, message fragment, and __cause__; it fails if the wrap is removed.
• Leaves the existing HTTP >= 400 tagging path untouched; no MCP/CLI surface churn needed.

Review path

• Checked out the PR tip, ran attachment_service unit tests (24 passed) and ruff on touched files; CI green.
• Callers (facade, MCP tools, CLI) already catch AttachmentUploadError and benefit from the step tag.
• Coverage polish (allowlist ValueError in the service unit test) matches the intentional KB twin gap and was verified manually with HttpxS3Uploader; not a merge gate.