fix: add batch eval and recommendation IAM permissions to docs

[notgitika]

Summary

• Add BatchEvalAndRecommendations statement to iam-policy-user.json with 9 actions for batch evaluation and recommendation APIs
• Add CloudWatch Logs write permissions (CreateLogGroup, CreateLogStream, PutLogEvents, DescribeLogGroups) to LogsStreamingAndSearch — needed because the batch eval API creates a log group for results output
• Update PERMISSIONS.md with batch eval/recommendations reference section, updated logging entries, and scoping-down table entry
• Fix e2e test: config-bundle-eval-rec.test.ts searched for resourceType === 'configBundle' (camelCase) but the status command outputs 'config-bundle' (kebab-case)

Also applied logs:CreateLogGroup/CreateLogStream/PutLogEvents to the e2e-github-actions IAM role in the test account so CI passes immediately.

Context

E2E tests in shard 5/6 were failing with:

1. Batch eval 403: FAS credentials do not have permission to create CloudWatch log groups — the batch eval API writes results to a CloudWatch log group and needs logs:CreateLogGroup
2. Config bundle status: Config bundle "E2eTestBundle" should appear in status: expected undefined — the test used camelCase configBundle but the status command outputs kebab-case config-bundle

Test plan

• iam-policy-user.json is valid JSON
• prettier --check passes on all changed files
• Applied IAM changes to e2e-github-actions role in test account
• Re-run E2E shard 5/6 to confirm batch eval and config bundle status tests pass

[agentcore-cli-automation]

The actual fix commit (6837467) is tight and correct — the 9 bedrock-agentcore:* actions line up with the API operations in agentcore-batch-evaluation.ts and agentcore-recommendation.ts, the logs additions are documented in the scoping-down table in PERMISSIONS.md, and the configBundle → config-bundle test fix matches the actual output in src/cli/commands/status/action.ts:250. That part all looks good.

However, there's one serious issue with the PR as a whole: the branch is based on preview but targets main, so in addition to the intended 3-file change it's pulling in ~137 commits and ~180 unrelated files from the preview branch (harness code, recommendations, batch eval, ab-tests, config-bundles, new workflows, CHANGELOG/package.json version bumps, etc., totaling roughly +16k/-943 lines). The PR description only describes the 3-file IAM/test change, so merging as-is would silently land a huge amount of preview-only work into main.

A couple of ways to fix this:

1. Cherry-pick onto main. Create a new branch off origin/main and cherry-pick 6837467 onto it, then repoint the PR (or open a new one). This is the cleanest option given the scope mismatch with the description.
2. Retarget the PR to preview. If the intent is actually to land this on the preview branch first (and let it reach main via the normal sync-preview flow), change the base from main to preview. The diff will then be just the 3 files the commit touches.
3. Intentionally promote preview → main via this PR. If you actually do want all 137 preview commits to land in main now, the PR title/description should reflect that (and it should probably go through whatever the standard preview→main promotion path is rather than riding on a "fix" PR).

Option 1 or 2 seems most likely given the description. Worth sanity-checking which one matches intent before merging.