⭐ expose initProcessEnabled on ECS container definition

[tas50]

Summary

• Adds initProcessEnabled bool field to the aws.ecs.taskDefinition.containerDefinition resource schema
• The Go code already populated this field from LinuxParameters.InitProcessEnabled but it was missing from the .lr schema, so MQL queries couldn't reference it
• Bumps AWS provider version to 13.5.1

Test plan

• Verify aws.ecs.taskDefinitions { containerDefinitions { initProcessEnabled } } returns data in cnquery shell -t aws
• Verify cnspec policy lint passes for the new mondoo-aws-security-ecs-init-process-enabled check

🤖 Generated with Claude Code

[mondoo-code-review]

New initProcessEnabled field on ECS container definitions is never populated, always returning false

Additional findings (file/line not in diff):

• 🔴 providers/aws/resources/aws_ecs.go:963 — The initProcessEnabled field is declared as a plain property in .lr (not a computed method), so it must be set at CreateResource time. However, the CreateResource call here does not include "initProcessEnabled", so it will always default to false.

The data is already extracted for aws.ecs.container at line ~498-499 via cd.LinuxParameters.InitProcessEnabled. Apply the same logic here:

initProcessEnabled := false
if cd.LinuxParameters != nil && cd.LinuxParameters.InitProcessEnabled {
    initProcessEnabled = true
}

Then add "initProcessEnabled": llx.BoolData(initProcessEnabled) to the CreateResource map.

[mondoo-code-review]

New ECS container definition field initProcessEnabled is exposed as a direct property instead of a lazy-loaded method, inconsistent with its .lr declaration.

Superseded by new review

[mondoo-code-review]

New ECS field correctly defaults to false when AWS API returns nil, matching AWS documented behavior.

[github-actions]

Test Results

5 741 tests  ±0   5 737 ✅ ±0   2m 28s ⏱️ +27s
  425 suites ±0       4 💤 ±0 
   33 files   ±0       0 ❌ ±0 

Results for commit 0220336. ± Comparison against base commit 4c82ae0.