Rectify reclaimed fresh-path cleanup disclosure

[lamemustafa]

Problem

Fallback cleanup can name a reclaimed foreign fresh destination as a retained owned output when the created pin has zero links, which may direct an operator toward another writer’s data.

Acceptance

• Suppress reclaimed names on the identity-proven fresh fallback path.
• Add a race control that verifies foreign paths are neither removed nor named as retained owned output.

Discovered on PR #320 and deferred under the owner-authorized P1-only stopping rule.

[lamemustafa]

Taking this. Same file and same #320 lineage as #352/#353, which I closed out just now — #353 fixed in #425, #352 verified already done.

[lamemustafa]

Diagnosed precisely but not implementing it — read the last paragraph for why.

Where it is

_unlink_for_cleanup (scripts/bank_statement_import.py:1573) names a reclaimed path deliberately, and says so:

if state == "reclaimed":
    # The pathname has been reclaimed. It is not ours to delete, and
    # reporting it gives the operator a chance to find the private copy
    # if it still exists without making a claim about foreign bytes.
    failures.append(str(path))
    return "reclaimed"

That rationale is sound in general: the operator may still find their own copy near that name, and the message deliberately stops short of claiming the bytes are theirs.

Why the fresh fallback path is different

On the identity-proven fresh fallback (:1692-1719), the caller holds the created pin. If that pin proves zero links, this run's inode is definitively gone — there is no private copy to find. The justification for naming the path evaporates, and what remains is a pathname that now belongs to another writer, printed to an operator under a heading about retained output.

So the defect is not "naming a reclaimed path" — it is naming one in the single case where the reason for naming it is known to be false.

Why the neighbouring code does not have this problem

_reconcile_owned_pin_after_cleanup (:1847) already gets this right: it names the path only when the pin proves the inode is still linked (st_nlink > 0). The fresh fallback reaches _unlink_for_cleanup first, which has no access to the pin and so cannot make that distinction.

That is the shape of the fix: the caller knows the link count, _unlink_for_cleanup does not, and the decision is being made in the function that lacks the information.

Why I am stopping here

This is recovery code in a tool that writes financial imports, and the change is a semantic one about what an operator is told after a failed run — not a typed-refusal translation like #353. Getting it wrong in the other direction suppresses a name the operator needed. It also wants the race control the acceptance criteria ask for, which means constructing a genuine reclaim between two runs rather than asserting a boolean.

I have been working this file for a while and this one deserves a fresh reader rather than my tenth hour. The diagnosis above is the part that was missing; the implementation should be someone's first task, not my last.

Unclaiming. #353 is fixed in #425 and #352 is verified already-done, both with comments recording the evidence.

[lamemustafa]

Picking this up. I diagnosed it at the end of a long session and deliberately left it for a fresh reader — this is that, first task of a new session.