fix: make Git-submodule takeover failure-atomic

[ORESoftware]

Superseded by #101 after compacting the identical four-file tree into one intentional commit. GitHub does not permit reopening a PR whose head branch was force-recreated.

Context

PR #96 merged the requested Git-submodule interoperability surface:

• opt-in zed install --git-submodules[=true|false];
• ZED_PKG_GIT_SUBMODULES and matching .cli-flags.toml metadata;
• recursive, explicit-checkout submodule synchronization before ordinary Zed resolution;
• zed overtake --git-submodules for importing committed Zed-package submodules into workspace/dependency authority; and
• additive, frozen-verifiable [[git-submodule]] provenance in .zpkg.lock.

A post-merge transaction audit found one narrow migration edge: overtake committed the candidate .zpkg.toml before invoking the ordinary installer. A resolution or materialization failure could therefore leave a half-adopted root manifest even though the installer correctly rolled back its own lock and materialized tree.

Hardening

• snapshot and parse the same exact prior root-manifest bytes;
• verify the manifest has not changed before applying takeover intent;
• restore the exact prior bytes when installation fails before commit;
• remove a newly generated root manifest when none existed before takeover;
• refuse rollback if another writer changed the candidate manifest;
• reacquire the global install lock before rollback recovery;
• distinguish additive Git-lock finalization failures after the ordinary install transaction commits;
• add focused unit and end-to-end rollback coverage; and
• document the failure and reconciliation contract.

Follow-up to #96 and DEN-1612.

[linear-code]

DEN-1612