fix: honor --s3-root-uri and --conflict-resolution in attachment CLI

[crowecawcaw]

Fixes:

What was the problem/requirement? (What/Why)

Two arg-plumbing bugs in the attachment CLI group:

• attachment download raised a RuntimeError in the config-defaults workflow: --conflict-resolution was not stripped from the args in the else-branch cleanup of _apply_cli_options_to_config, so a leftover {"conflict_resolution": None} reached the if args: raise RuntimeError(...) guard.
• --s3-root-uri was ignored/overwritten unless --profile was also passed, because the no-profile path unconditionally recomputed the S3 root URI.

What was the solution? (How)

• Add conflict_resolution to the standard-option cleanup list in _apply_cli_options_to_config.
• Guard the S3-root-URI recompute with if not s3_root_uri: in both attachment download and attachment upload (same shared option, same fix) so an explicit --s3-root-uri is honored regardless of --profile.

What is the impact of this change?

attachment download works in the config-defaults workflow, and --s3-root-uri is respected on its own.

How was this change tested?

Added red-green tests: the config-defaults download no longer raises, and --s3-root-uri is passed through without --profile for both download and upload.

• Have you run the unit tests? Yes — new test_cli_attachment_args.py (3 tests) plus regression runs of test_cli_common.py/test_cli_job.py.
• Have you run the integration tests? No.

Was this change documented?

• No public-contract change; behavior now matches documented intent.
• README.md not affected.

Does this PR introduce new dependencies?

• This PR adds one or more new dependency Python packages.
• This PR does not add any new dependencies.

Is this a breaking change?

No.

Does this change impact security?

No. (The separate manifest-upload disclosure / CAS-poisoning concern (C4) is out of scope and tracked separately.)

Testing

Automated coverage (test/unit/deadline_client/cli/test_cli_attachment_args.py, 9 tests, all invoking the real CLI via CliRunner):

• --conflict-resolution omitted in the config-defaults workflow no longer trips the _apply_cli_options_to_config RuntimeError (download).
• --conflict-resolution SKIP is threaded through to the _attachment_download call (not just consumed).
• Explicit --s3-root-uri is honored without --profile for both download and upload, including when it would otherwise be overwritten by the queue's settings.
• Explicit --s3-root-uri works even when the queue has no jobAttachmentSettings (both download and upload).
• Failure mode preserved: with no --s3-root-uri and no queue attachment settings, the command still fails with MissingJobAttachmentSettingsError and never reaches the download.

Manual verification (scratch script driving deadline attachment download/upload end-to-end through click with mocked deadline/S3 clients) confirmed all of the above scenarios pass, including that the explicit URI (s3://manual-check-bucket/...) wins over the queue-provided bucket.

End-to-end S3 verification (moto): two additional tests run attachment download/upload with no job-attachments internals mocked — the queue-role credential path (AssumeQueueRoleForUser), real manifest decoding, and the real S3 transfer code all execute against moto S3 with both the queue's configured bucket and the explicitly-named bucket created. They prove the transfer actually touches the explicit bucket: download reads its content instead of a same-CAS-key decoy planted in the queue's bucket, and upload writes the CAS object + manifest to the explicit bucket while the queue's bucket stays empty.

The only thing still not covered by automation is real-AWS IAM: whether a given queue role's policy actually grants access to a caller-chosen bucket. That's an account-configuration concern rather than client-code behavior, so no hands-on testing of this change is required.

[github-actions]

The new comment says an explicit --s3-root-uri must be honored "even when the queue has no attachment settings of its own", but get_queue(...) (lines 126-130) is still called unconditionally before this check. So when a caller supplies --s3-root-uri precisely to operate without relying on queue settings, they still incur a GetQueue call — and if that call fails (e.g. AccessDenied, or the queue does not exist), the command errors out before ever reaching this branch, defeating the intent. Consider moving the get_queue(...) lookup inside the if not s3_root_uri: block so it is only performed when the fallback is actually needed.

[github-actions]

Same as in attachment_download: get_queue(...) (lines 244-248) is still called unconditionally, so an explicit --s3-root-uri does not actually let a caller bypass the queue lookup. If GetQueue fails (AccessDenied, missing queue), upload errors out before reaching this fallback branch, contradicting the "must always be honored, even when the queue has no attachment settings" comment. Move the get_queue(...) call inside if not s3_root_uri:.