[ECR] [request]: Validate prospective registry or repository policies more thoroughly before accepting them

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
What do you want us to build?

**Which service(s) is this request for?**
ECR

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

I recently went through a support case that dragged on for a long time, where ECR replication from one account and region to a different account and region was failing with `DESTINATION_REGISTRY_ACCESS_DENIED`. Ultimately the problem boiled down to this in the registry policy at the destination site:

```diff
< "Resource" : "arn:aws:us-east-2:012345678901:repository/*"
---
> "Resource" : "arn:aws:ecr:us-east-2:012345678901:repository/*"
```

(Account number changed to protect the innocent)

I didn't see the problem through several laps of reviewing the documentation. Support personnel working my case didn't see it either. It was not until they prompted me to review it yet again that I spotted the discrepancy.

The documentation is correct, but a career IT staffer with many years experience, including several years working extensively in AWS, missed this several times. The support staffers working the case missed it several times. The infrastructure-as-code on our side didn't spot it. The ECR service didn't spot it either, and it happily accepted something ARN-like that was utterly useless and would never match, without so much as a warning. The AWS CLI provided no error or warning messages.

I fear that others may fall into the same trap of several levels of lack-of-feedback, exacerbated by the feeble human eyes-to-brain connection sometimes only seeing what it wants to see and not what is actually there.

Please update the ECR service so that it catches implausible ARNs in the `Resource` section of a registry or repository policy. At least it could have recognized that the ARN I provided had the wrong number of segments(?), lacked the substring `ecr`, and thus would never match an ECR repository. It is obvious to me now, but a month ago my eyeballs easily slipped over it.

**Are you currently working around this issue?**

I revised the validations in our infrastructure-as-code to only insert valid ECR-related ARNs in the registry policy.

Changing the human comprehension and detection factor may be more challenging.

**Additional context**

None

**Attachments**

None

Start with the ECR registry and repository policy behavior described in the issue, especially the Resource ARN example and the DESTINATION_REGISTRY_ACCESS_DENIED failure. Determine how prospective policies are currently accepted and define completion as rejecting or warning on implausible ECR ARNs that cannot match an ECR repository; no source files or tests are named.

Written by the indexing model from the issue text.