fix(install): handle shallow pinned updates - #428

Context

Addresses the non-blocking follow-up findings from the review on #419.

What changed

• Documented that direct sh install.sh from a source checkout still installs from the configured repository at the default release tag, not from the invoking working tree.
• Added a shared pinned-SHA checkout helper for clone installs.
• Fixed existing shallow managed clones so --sha reinstalls fetch advertised heads/tags before failing a pinned commit checkout.
• Added focused Bats coverage for the existing shallow clone update path.

Verification

• shellcheck --severity=warning install.sh test/bats/05-install.bats — passed.
• ./scripts/test-acq-bats test/bats/05-install.bats — passed, 3 tests.
• npm run lint:md — passed, 0 issues.
• git diff --check — passed.
• Live scratch regression with a real shallow tag clone and a later arbitrary commit SHA — passed; installer updated the existing shallow clone to the pinned SHA.

Rollback

Revert this PR. The installer will return to the PR 419 behavior where fresh clone SHA pinning can deepen shallow history but existing shallow managed clones do not have the same fallback.

Security impact

Positive supply-chain correctness impact: existing shallow managed installs now honor pinned commit installs consistently with fresh installs. No authn/authz paths, secret handling, sandbox permissions, or network allowlists are broadened.

AI assistance

AI-assisted implementation with human review required before merge.