Mid-cycle `scan` is blocked by a "regenerates issue IDs and breaks triage state" warning, but the documented workflow always involves scanning mid-cycle

[Vuk97]

desloppify version: 0.9.15
Severity: workflow friction, requires repeated --force-rescan ceremony

Bug

The documented loop is: next → fix code → resolve → scan to see the impact. But scan refuses to run when the queue still has items, with this message:

$ desloppify scan --path .
  Excluding (from config): target
  4 items remaining in your queue.
  Scanning mid-cycle regenerates issue IDs and breaks triage state.
  Work through items with `desloppify next`, then scan when clear.

  To force a rescan (resets your plan-start score):
    desloppify scan --force-rescan --attest "I understand this is not the intended workflow and I am intentionally skipping queue completion"

This is a paradox: the workflow REQUIRES rescanning to see the score impact of resolved items, but the queue is rarely empty (subjective items, stale items, planning steps). To make progress, the user must add --force-rescan --attest "I understand ..." to every single scan invocation. Across a multi-hour session that's hundreds of redundant flag-strings.

Steps to reproduce

$ desloppify resolve some-issue --confirm
  ... resolved
$ desloppify scan --path .
  4 items remaining in your queue.
  Scanning mid-cycle regenerates issue IDs and breaks triage state.

$ # add the force flag + attest:
$ desloppify scan --path . --force-rescan --attest "I understand this is not the intended workflow and I am intentionally skipping queue completion"
  ... runs

I had to type or copy that attest string ~30 times in a single session.

Expected behavior

One of:

1. Allow scan when queue items are subjective-only or planning-only — those items don't get regenerated by a scan, only objective issue IDs do.
2. Persist the --force-rescan --attest consent for the session — once acknowledged, don't ask again until a meaningful state change.
3. Print the workflow as a single command shortcut: desloppify rescan that bundles --force-rescan --attest ....
4. Just rename the long attest to a -y / --yes flag for the impatient developer path.

Impact

A core workflow command (rescan to verify a fix) is gated behind a 130-character ceremony string. The friction discourages the "fix → verify → fix → verify" cycle the tool's own docs recommend.