test(loop-sandbox): use the public lock subpath in the test suite

[shixi-li]

Summary

Finish the migration #448 started: loop-sandbox's test suite still imports the lock API through the legacy deep path, one line after the src import that #448 already moved onto the public subpath.

tools/loop-sandbox/test/sandbox.test.mjs
- import { lockPaths, listLocks } from '@cobusgreyling/loop-worktree/dist/lock.js';
+ import { lockPaths, listLocks } from '@cobusgreyling/loop-worktree/lock';

With this, the sandbox tests exercise the same public /lock contract that src/sandbox.ts now uses (both lockPaths and listLocks are part of the subpath surface added in-repo by #407; the npm publish of 1.3.1 is still pending per RELEASE_NOTES_DRAFT.md). Resolution is unaffected in every context that runs this test: loop-sandbox's lockfile records the dependency as a workspace link to ../loop-worktree, so both local runs and the release workflow's npm ci resolve the in-repo tree, never the registry.

tools/loop-worktree/test/package-exports.test.mjs is deliberately not touched: its dist/lock.js import is the guard for the legacy escape hatch (“exposes the public lock subpath and keeps legacy deep imports”), so it stays as the single intentional consumer of the deep path.

Validation

• cd tools/loop-sandbox && npm test — 10/10 before the change (baseline) and 10/10 after, 0 skipped (node 24, npm 11.13.0)
• cd tools/loop-worktree && npm test — all passing, exit 0
• Negative control, both directions, with the "./dist/*" passthrough temporarily removed from loop-worktree's exports:
  • new /lock import → still 10/10 (the public subpath does not depend on the legacy passthrough)
  • old dist/lock.js import → fails with ERR_PACKAGE_PATH_NOT_EXPORTED (confirms the import line is genuinely exercised and was the last consumer riding the escape hatch outside the exports guard test)

Follow-up to #407 / #448.