ds scan re-baselines ds:claim about=: a changed block stops expiring the claim without an ack #6

Version: ds v0.1.8 (commit eb1cb8f)

Repro

mkdir -p /tmp/ds-claim/src /tmp/ds-claim/docs && cd /tmp/ds-claim
git init -q -b main . && ds init >/dev/null
printf 'export function makeThing(a: number): number {\n  return a + 1;\n}\n' > src/thing.ts
cat > docs/a.md <<'MD'
# Kit

<!-- ds:def id=thing-api-a2b2c3d4 file=src/thing.ts pick=symbol:makeThing stability=api -->

Call `makeThing` to add one. <!-- ds:claim owner=@kit reviewed=2026-10-14 expires=3650d about=thing-api-a2b2c3d4 -->
MD
git add -A && git commit -qm a && ds scan && ds check      # 1 ok
sed -i.bak 's/a: number)/a: string)/' src/thing.ts && rm src/thing.ts.bak
ds check; echo "exit $?"    # error: expired, claim is about thing-api-a2b2c3d4, which changed (signature); exit 1
ds scan
ds check; echo "exit $?"    # 1 ok; exit 0

Expected

After the block changes, the claim stays expired until someone renews it with ds ack --doc docs/a.md --line 5, the same way a ds:block citation stays unacked across scans (its first-seen hash is kept in refs.tsv).

Actual

ds scan re-baselines the claim: once the ledger records the new block, ds check reports ok and exits 0. No ack was recorded, and nobody reviewed the sentence.

For comparison, a ds:block citation of the same def ([makeThing](ds:block?id=thing-api-a2b2c3d4)) stays unacked after the same ds scan.

Impact

ds scan is the normal step after any edit (the getting-started guide runs it before committing), so in practice an about= claim almost never fires: the change is accepted silently by whoever scans next. A gate built on ds check therefore passes on exactly the change the claim exists to catch.