cli/manifest: opt-in flag gating transitive dependency resolution

Summary

Phase 2 of #68 (depends on the design decision issue; independent of the resolver internals — can be developed in parallel against a stub resolver signature). Add the user-facing opt-in surface for transitive resolution, per the trust-model decision.

Scope

• Add the opt-in mechanism decided in the design sub-issue (e.g. spm add --with-deps, and/or a manifest-level flag validated by src/schema.rs/schema/ai.schema.json).
• Wire the flag through src/cli.rs command dispatch so it's threaded to wherever resolution is invoked (sync/add/update).
• When the flag is off (default, if opt-in was chosen), transitive resolution must not run at all — nested ai.json files are ignored, preserving current behavior exactly.
• Tests: schema validation for the new manifest flag (if applicable), CLI argument parsing/dispatch tests in tests/cli.rs.

Out of scope

The actual recursive resolution logic (separate sub-issue) — this issue only adds the on/off surface and threads it through.

Relevant code

• src/cli.rs, src/manifest.rs, src/schema.rs, schema/ai.schema.json, tests/cli.rs

Part of #68.

Start with the design decision sub-issue in #68, then inspect src/cli.rs, src/manifest.rs, src/schema.rs, schema/ai.schema.json, and tests/cli.rs. Implement the decided opt-in surface and thread it through the sync/add/update dispatch paths without implementing recursive resolution. Done means the flag is validated and parsed as applicable, CLI tests pass, and the default-off behavior preserves nested ai.json files as ignored.