DEN-3038: generate and certify exact Zed lock + Git-submodule dual-pin canary #146

Context

Implements the generated-fixture side of DEN-3038 and supports the cross-org architecture program in DEN-3033.

The generated zed-pkg-test/api-contract-e2e fixture currently has internally consistent Git evidence on main:

• .gitmodules maps vendor/zed-clients to https://github.com/zed-pkg/zed-clients.git;
• source-pins.json records zed-pkg/zed-clients@c97ead9ce1cd3675be7704d35e2395fa59f4baa4;
• the actual vendor/zed-clients gitlink is the same commit;
• .zpkg.toml declares zed-pkg/zed-clients = "^0.1.0".

The missing proof is a committed Zed resolution/lock that binds that package dependency to immutable provenance. Without .zpkg.lock or an equivalent canonical resolved record, the fixture cannot prove that the Zed edge and the Git gitlink resolve to the same source revision.

Required change

Update the fleet manifest/bootstrapper, then regenerate the fixture. Do not hand-edit generated output.

1. Generate a committed .zpkg.lock or canonical resolved-Zed provenance record for the zed-pkg/zed-clients dependency.
2. Add a central validator that normalizes the Zed package edge and Git-submodule edge into one logical dependency while retaining both provenance records.
3. Require canonical repository identity agreement and exact revision compatibility.
4. Record exact fixture commit, producer commit, lock digest, gitlink SHA, and validator version in machine-readable evidence.

Positive canary

• .gitmodules URL/path, gitlink SHA, source-pins.json, .zpkg.toml, and .zpkg.lock agree;
• the graph emits one logical dependency with separate zed and git-submodule provenance;
• repeated/frozen resolution is deterministic and credential-free.

Negative canaries

• Zed lock resolves a different source commit than the gitlink;
• canonical repository identities disagree despite similar names;
• a second physical checkout is created for the same adopted-workspace dependency;
• runtime code shells out to the Zed CLI;
• branch/gitlink update is non-fast-forward;
• manifest, lock, URL, or evidence contains GitHub/Linear/Cloudflare/S3-R2 credential-shaped content.

Each negative must fail for its intended assertion, and mutation tests must prove the checks are non-vacuous.

Safety

• draft PR and generated-fixture regeneration only;
• no production repository/default-branch/provider mutation;
• no cross-organization write credential in pull-request jobs;
• protected/live evidence remains separate from credential-free contract validation;
• keep zed-pkg-test/api-contract-e2e generated from the central fleet source.

Acceptance

• fleet source and regenerated fixture are linked in a draft PR;
• committed immutable Zed resolution exists;
• positive dual-pin case passes;
• every deliberate negative fails for the intended reason;
• exact-head evidence links back to DEN-3038 and the architecture registry;
• CI unavailability is reported distinctly from contract failure.