fix(changed): guard the index, which is the tree the sandbox comes from

[Disble]

CI refuted the guard in fifty-one seconds, on the very first run of the gate it
was written to protect:

checking the checkout: ditto: a range scope measures committed bytes,
and this checkout has uncommitted work:
    M devbox.lock

The Devbox install step modifies a tracked lockfile that has nothing to do with
any change, and the gate refused to run at all.

The condition was wrong, not merely strict

The sandbox is git checkout-index --all, so it holds the index. A range
scope names bytes of HEAD. Those agree exactly while the index agrees with
HEAD — which is narrower than a clean worktree.

A worktree modification is never written into the sandbox, so it cannot move a
verdict; refusing it only stops runs that would have been correct. A staged
change is written into it, and running then would mean scoping against one tree
while mutating another — the defect measured at seven of eight verdicts moving,
and silent.

So the check is git diff --cached --name-only, and the method is named for
what it actually asks.

Tests

The public test keeps the refusal. The allow case is pinned in internal/staged
rather than at the top, because allowing it there would run a real release to
prove that a guard did not fire — the first version of this change did exactly
that and took 50 seconds to say so.

Readme, changelog and backlog entry 21 all corrected: they described the wrong
condition too.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud