Support target-scoped generated command package resource projection

[rickardvh]

Origin: rickardvh/agentic-workspace#1253

Current status

Target-extension contracts now exist through command-generation #17. This issue should use that contract boundary rather than deciding target-scoped metadata as a standalone one-off question.

Problem

Generated TypeScript package resources can carry the full command package record, including metadata for other targets. A full cross-target resource may be intentional for introspection, but the generator should either expose a target-scoped projection or document/enforce why every generated target ships the full cross-target package record.

Desired outcome

Decide and encode whether generated target packages ship full cross-target package records or target-scoped command package resources, using command-generation/target-extension/v1 to make target-owned versus host-owned metadata explicit.

Acceptance

• The decision is represented through target-extension-aware metadata, docs, or checks.
• If target-scoped, rendered resources omit target-irrelevant runtime bindings such as Python runtime binding details from TypeScript-only runtime packages.
• If full cross-target metadata is intentional, documentation and tests prove target runtimes do not treat target-irrelevant bindings as executable fallback behavior.
• A TypeScript or other non-Python fixture/check covers the selected behavior.
• The chosen model remains compatible with AW target support declarations and does not let targets own product operation semantics.

Out of scope

• Re-litigating the existence of target-extension contracts from Add target extension contract #17.