lockfile: extend ai.lock schema to represent a skill dependency graph

Summary

Phase 1 of #68 (depends on the design decision issue). Extend src/lockfile.rs's LockedSkill/Lockfile shape so a transitively-resolved skill can record which top-level (or intermediate) dependency requested it, while keeping the flat, deduplicated-by-(git, commit, path) list as the source of truth for materialization.

Scope

• Add a field (e.g. requested_by: Vec<String> or similar, per the design decision) to LockedSkill to preserve provenance for diagnostics, without breaking existing lockfiles (must remain backward compatible / additive-only per serde defaults).
• Extend validate()/validate_locked_map in src/lockfile.rs to validate any new fields with the same untrusted-input rigor as existing ones (path traversal, name collisions, etc.).
• Unit tests covering serialization round-trip, backward compatibility with existing ai.lock fixtures, and validation of the new field(s).

Out of scope

Actually populating the new field via recursive resolution — that's the resolver sub-issue. This issue only prepares the data shape so the resolver and spm list/status work can proceed in parallel against it.

Relevant code

• src/lockfile.rs

Part of #68.

Read the design decision in #68 first, then inspect src/lockfile.rs and the LockedSkill/Lockfile definitions. Extend the data shape additively, update validate() and validate_locked_map for the new fields, and cover serialization round-trips, existing ai.lock compatibility, and validation cases. Done means provenance can be represented without changing the flat materialization source of truth.