EC2 authz: the ID resolver runs for operations AWS says have no resource-level permissions

[scttfrdmn]

buildResourceARNs' EC2 arm resolves an operation's InstanceId.N, GroupId.N,
RouteTableId.N and InternetGatewayId.N into per-resource ARNs, for every operation that
carries one of those parameters. #730 established that for a single ID and #744 extended it to
every ID a request names. Neither decided whether the resolution should happen for operations
AWS says do not support resource-level permissions.

It should not, for those operations. AWS's Example policies to control access to the Amazon EC2
API states that ec2:DescribeInstances does not support resource-level permissions, so a real
request's resource is * and a policy scoping ec2:DescribeInstances to an instance ARN grants
nothing on AWS. Substrate resolves the IDs, so the same policy grants exactly those instances
here — a false allow in the policy author's favour, and the opposite of the deny-side
divergence that usually shows up first. A consumer who tests a scoped describe policy against
substrate learns it works, and it does not.

The four parameters are read by more than the describes, so the fix is not "skip describes":
it is a per-operation statement of which EC2 operations support resource-level permissions,
which is a table AWS publishes per action in the Service Authorization Reference. That is the
work, and it is a decision about #730's resolver rather than about #744's expansion of it —
which is why it was carved out of both.

Acceptance criteria

• An EC2 operation AWS documents as not supporting resource-level permissions is authorized
  against *, so a policy scoping it to an ARN grants nothing — as on AWS.
• The operations that do support them keep the per-ID resolution iam: the keys the bundled policies condition on have no producer #730 and EC2 authz: an operation naming several IDs is decided against the first alone #744 built,
  including the multi-resource expansion and the per-resource tags.
• Whichever way each operation is classified, the source is cited — the Service
  Authorization Reference row, not built-in knowledge.
• docs/services.md stops recording the describe divergence as deliberately left, and the
  sentence naming this issue is removed.
• A test pins at least one operation on each side of the line, including that a scoped
  DescribeInstances policy no longer narrows anything.

Carved out of #744 (v0.109.0).