fix(dirty-set): correct lockfile detection in the fallback trigger

[honnix]

isFallbackTrigger matched lockfiles by substring on the basename, and erred in both directions.

Missed real lockfiles carrying .lock as an inner component — multitool.lock.json, .terraform.lock.hcl. This is the dangerous direction: the file belongs to no target's edges, so nothing is marked dirty, every target keeps its seed hash, and impacted targets are silently under-reported. In one monorepo tools/multitool.lock.json changed 33 times in the last 90 days, each time without a fallback.

Caught unrelated files whose name merely contains -lock. or _lock. — a git merge driver (merge-pnpm-lock.sh), a PNG, an XML, three SQL migrations and three markdown documents, each forcing a full rehash of ~444k targets.

A .lock extension now always triggers. The ambiguous inner-component and name-stem forms additionally require an extension a lockfile could plausibly use; an unrecognised extension stays conservative and still triggers.

basename	before	after
multitool.lock.json	false	true
.terraform.lock.hcl	false	true
merge-pnpm-lock.sh	true	false
2x-lock.png	true	false
V3__workflow_lock.sql	true	false
pnpm-lock.yaml, Cargo.lock, buf.lock	true	true
deps-lock.xyz (unknown ext)	true	true

Test plan

• TestIsFallbackTriggerLockfiles covers all of the above plus the unknown-extension case.
• TestComputeDirtySetNestedLockExtensionFallsBack and TestComputeDirtySetLockNamedScriptDoesNotFallBack cover it end to end through ComputeDirtySet.

Note: I could not run go test locally — the module proxy was unreachable and the generated protobuf deps would not resolve offline. The table was verified against a standalone copy of the function (all 20 cases pass); CI should be treated as the real check.