using a different artifact repository in different steps/tasks ?

## Summary

at the moment, you can crate a ConfigMap named artifact-repositories with multiple repositories

then, inside each workflow, you can specify the repo to use with artifactRepositoryRef

however, if you need step1 to read from the repo1 and to write to repo2, you need to choose one of the 2 repos as a "default" (and to repeat the repository info into the other one)

If you could apply the artifactRepositoryRef at step level (or task level for a DAG), it will solve the problem

something like :
```yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: input-artifact-s3-
spec:
entrypoint: input-artifact-s3-example
templates:
- name: input-artifact-s3-example
inputs:
artifacts:
- name: my-art
path: /my-artifact
artifactRepositoryRef: repo1
s3:
key: path/in/bucket
container:
image: debian:latest
command: [sh, -c]
args: ["ls -l /my-artifact"]
```

Please note that my use case is not really to use different repos in the same workflow, but only different buckets

however, at the moment, if you do (assuming you configured an artifact repo named repo1) :

```
kind: Workflow
metadata:
generateName: input-artifact-s3-
spec:
artifactRepositoryRef: repo1
entrypoint: input-artifact-s3-example
templates:
- name: input-artifact-s3-example
inputs:
artifacts:
- name: my-art
path: /my-artifact
s3:
bucket: my-other-bucket #here, this should "override" the bucket configured in repo1
key: path/in/bucket
container:
image: debian:latest
command: [sh, -c]
args: ["ls -l /my-artifact"]
```

then the bucket key is NOT used (argo is still looking in the bucket that is configured inside repo1)

do not hesitate to ask me more details

---

**Message from the maintainers**:

Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

Start by tracing how artifactRepositoryRef is resolved for workflows and artifact inputs, and how S3 bucket settings are applied. Compare the requested step- or task-level repository selection with bucket-only overrides, then identify the relevant workflow and artifact-resolution tests. Done means each step or task can select the intended repository or bucket without requiring a default repository workaround.

Written by the indexing model from the issue text.