feat(templates): wire in memory to the runtime templates

[Hweinstock]

Dependent on #2099 (ignore this until that is merged)

Problem

Memory is currently hardcoded to none. The old CLI defaulted to a real memory, and allowed none | longAndShort | short options.

Solutions

• mirror old CLI arguments for memory with the same default.
• wire that memory through to the template resolver.
• refactor the fsTreeNode asset resolver to accept transformations and filters for added flexibility.

Testing

• created a project with the memory template then deployed, verified the project and my cdk stack included a memory. Also verified the memory code was included in the asset rendering.
• unit tests!

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.22%. Comparing base (2595b9d) to head (13f6e95).

Additional details and impacted files

@@            Coverage Diff            @@
##           refactor    #2116   +/-   ##
=========================================
  Coverage     97.22%   97.22%           
=========================================
  Files           463      464    +1     
  Lines         28160    28227   +67     
=========================================
+ Hits          27378    27445   +67     
  Misses          782      782           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

I traced through the refactor and the new strands-http-python template. The extraction into templates/{project,runtime,harness,renderer,types,fsTree}.ts is coherent, the manager's addResource rollback semantics are preserved (mutating projectSpec in place is fine because it isn't written on the error path), the new fromTextFile correctly reads Dockerfile content from disk (so getHarnessTemplateResolver matches the old copyFile behavior, minus the pre-write existence check — the error is still thrown at write time via InputValidationError), and the manifest snapshot confirms memory/ is filtered out when --memory is not set.

Two very minor observations that are not blocking:

• mergeSpecEntries in src/core/project/templates/project.ts merges runtimes/credentials/memories but ignores harnesses, even though SpecEntries includes it. Currently unreachable since createProjectTree only invokes the runtime resolver, so the omission is harmless — worth fixing if a future template contributes harnesses at project-create time.
• src/assets/templates/strands-http-python/main.py references a pyJsonStr helper ({{pyJsonStr inputSchema}} and {{pyJsonStr litellmAdditionalParams}}) that isn't registered in HandlebarsTemplateRenderer. Guarded behind inlineFunctionTools / litellmAdditionalParams, both of which are never set in the current runtime.ts context, so it's latent — but it will blow up the day someone flips those flags on.

Neither of these needs to hold up the merge.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)