ADR-002: Tool provisioning via Dockerfile

[UltraBob]

Summary

• Dockerfile as the container-global tool floor using COMPOSER_HOME isolation (Martin's existing pattern)
• Project-level composer/npm becomes opt-in, not default
• Two cases for opting in: mixed-tooling teams (not everyone uses DDEV) and version pinning
• Vendor-wins precedence unchanged: project vendor/bin/ takes priority over container-global
• Host-side shims unaffected; they just get a reliable fallback instead of a dead end
• Version constraints match drupal/core-dev caret ranges, floating the same way upstream CI does

This is a layered approach: each package manager does what it's good at. The Dockerfile handles "tools just work," composer/npm handles "I need specific versions across my team."

Review checklist

• Does the layered approach (Dockerfile floor + optional composer) make sense for your workflow?
• Is the COMPOSER_HOME isolation pattern working well in ddev-module-developer today?
• Are the two cases for project-level install (mixed teams, version pinning) the right ones to call out?
• Any concerns about Dockerfile composition with other add-ons?

[UltraBob]

@mandclu another for your review

[mandclu]

Looks good to me. The existing pattern in ddev-module-developer has been working well