build: track workspace dependency resolution

[developer0hye]

Summary

• Track the workspace Cargo.lock, including exact Git revisions for branch patches.
• Make native, WASM, release-binary, and visual-evidence builds reject lockfile drift with --locked.
• Preserve the deliberate crates.io consumer-graph dry run by removing the lock only in that disposable CI checkout.
• Enforce the policy with a dependency-lock contract test.

Ignored per-worktree lockfiles allowed identical office2pdf commits to build different docx-rs and umya-spreadsheet revisions. The reviewed lockfile is now the single workspace resolution, while package verification still exercises what library consumers resolve without the workspace lock or patches.

Related issue

Related: #1412

Testing

• python3 -m unittest scripts.tests.test_dependency_lock_contract -v
• cargo metadata --locked --no-deps --format-version 1
• cargo check --locked --workspace
• cargo test --locked --workspace (2,824 core, 188 DOCX, 130 PPTX, 207 XLSX, CLI/package/doctests; zero failures)
• Workflow YAML parse check
• Disposable package probe confirmed removing Cargo.lock resolves the current consumer graph independently

Visual impact

• No rendered PDF change
• Rendered PDF change or visual evidence added
• Reason: This changes dependency-resolution and CI/release contracts only; converter code and rendered output are unchanged.

Checklist

• Commits include a Signed-off-by line
• PR scope contains one root cause
• Remaining visual deviations each reference an open issue (not applicable; no rendered change)

[developer0hye]

Exact-head CI run 33814942485 confirms the intended boundary: the locked workspace checks (including all three WASM cargo check variants) resolve the reviewed graph and pass, while only the deliberately unlocked Publish Verification consumer graph resolves tinyvec 1.13.0 and fails at src/tinyvec.rs:710 with cannot find macro vec in this scope.

This is the active upstream regression in tinyvec#225, with the exact fix already proposed in tinyvec#226. I will rerun this exact head after that release is corrected or yanked; adding a project-side suppression here would defeat the package-consumer compatibility gate.