AWS Kinesis input: validate DynamoDB permissions in the setup health check

Follow-up from #26898.

`KinesisService.healthCheck()` validates only Kinesis read actions, so a credential with zero DynamoDB rights passes the setup wizard and the input then fails at runtime. This is the layer that would have prevented Graylog2/graylog-plugin-enterprise#15073 rather than reporting it after the fact.

KCL 3.5 stores its coordination state in DynamoDB and needs actions that KCL 2.x did not, now listed in the AWS Kinesis/CloudWatch section of `UPGRADING.md`. The wizard could check the ones that are cheap to probe before the input is ever started, most usefully `dynamodb:Query` on `table/graylog-aws-plugin-*/index/*` and `dynamodb:UpdateTable` on the lease table.

Note `dynamodb:UpdateTable` is worth prioritising: #26898 established that a denial of it is not detectable at runtime at all. KCL fails to create the lease-table index, a KCL idempotence bug makes the second initialization attempt skip index creation entirely, and the input then starts and fails with `ResourceNotFoundException` rather than an authorization error.

A pre-flight check is also the only place that can catch a missing permission without waiting for the two-minute runtime detection window.

Start with KinesisService.healthCheck() and the AWS Kinesis/CloudWatch section of UPGRADING.md, which lists the newer KCL permissions. Trace how the setup wizard probes permissions, then define checks for dynamodb:Query on the KCL index path and dynamodb:UpdateTable on the lease table. Done means denied DynamoDB access is reported during setup rather than after the input starts.

Written by the indexing model from the issue text.