bug(harness): --no-memory omits memory instead of disabling it, so the service auto-creates managed memory

[aidandaly24]

Summary

agentcore add harness --no-memory (gated-off path) writes a harness spec that omits the memory config entirely. The AgentCore service treats an omitted memory config as "auto-provision a managed memory", so the harness ends up with a managed memory harness_<physicalName>_<hash> it never asked for — and the execution role isn't scoped for it, so invoke fails:

AccessDeniedException: not authorized to perform bedrock-agentcore:ListEvents
on resource memory/harness_<name>_<hash>

This is contributing to the harness-custom-jwt E2E failure (the test uses --no-memory).

Background

CDK #287 (managedMemory = spec.memory?.mode !== 'disabled') granted memory permissions for the omitted case precisely because the CFN Harness resource couldn't express a memory opt-out at the time, so "no memory" still got a service-auto-created memory that needed the grant.

That CFN limitation is gone: Memory: { Disabled: {} } shipped in the CDK (#273, alpha.20+) and the vended project resolves ^0.1.0-alpha.19 → the latest 0.1.0-alpha.39, which has it. So --no-memory should now emit an explicit disabled ref — a true opt-out — instead of omitting memory.

Fix

In the gated-off buildLegacyMemoryRef, return { mode: 'disabled' } for --no-memory instead of undefined. That maps to CFN Memory: { Disabled: {} }: no memory is created, no grant is needed, no AccessDenied.

CLI-only change; the CFN mapping and the schema's disabled arm are already live and ungated.