Do not treat dependency lock-file churn as a dirty worktree #68

Problem

Git::worktree_dirty (src/git.rs:829) is git status --porcelain non-empty. That means a single
npm install, cargo build refreshing Cargo.lock, or poetry lock is enough to classify an
otherwise finished worktree as dirty — pushing it into the force-removal multiselect
(src/cleaner.rs:530-600) where it is unselected by default and therefore silently survives every
run.

The result: worktrees whose work is fully merged accumulate forever, because a regenerable file was
rewritten by a routine command.

Proposal

Treat regenerable dependency lock files as if they were .gitignored when classifying dirtiness:

package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bun.lockb, bun.lock,
composer.lock, Gemfile.lock, Cargo.lock, poetry.lock, uv.lock, Pipfile.lock, go.sum,
flake.lock, gradle.lockfile, packages.lock.json.

Rules:

• A worktree whose only changes are lock files is not dirty.
• A lock-file change alongside any real edit is still dirty — we are not filtering the diff, only
  answering "is there anything but lock churn here".
• Opt out with --no-ignore-locks and sync.ignorelocks = false in git-config, following the
  existing precedence (CLI > git config > default) in resolve_* (src/main.rs:424-449).

Also worth covering under the same mechanism, but unconditionally (no opt-out): session marker
files that agent harnesses drop into the worktrees they create (e.g. a .qwen-session pointer).
A session pointer is never authored work, and leaving it counted brands every agent-created
worktree dirty forever.

Acceptance

• Only Cargo.lock modified → not dirty.
• Cargo.lock + src/main.rs modified → dirty.
• --no-ignore-locks restores the strict behaviour.
• Session-marker-only change → not dirty, with or without --no-ignore-locks.
• README option table and git sync config docs updated.