fix(frontend): keep a file attachment a stale file-list response omits (#14541)

* fix(frontend): keep a file attachment a stale file-list response omits

The chip on a file-input node was a projection of the file-list cache, and
the same component rewrote the node's stored value from that cache. A list
response that did not mention the attached file fell through to
`?? ""`, so one read that had not caught up with the upload cleared
value/file_path. The clear was persisted with the flow and was terminal:
with nothing selected, no later, correct response could restore it.

Absence is no longer reconciled. Names are reconciled only for paths the
list does report (so renames still land), and a selected path the list
omits keeps the name it was attached with. Removal stays an explicit user
action - the chip's remove button or the file manager.

The trigger button now keys off the files actually rendered rather than
the raw selection, so a selection the cache cannot render shows "Select
file" instead of an empty, un-actionable box.

* fix(frontend): verify a file is gone before dropping it from the node

The first version of this fix stopped reconciling absence altogether, which
also stopped a genuine delete from clearing the field: a file deleted in
file management stayed attached to the node as a dangling path. That broke
fileUploadComponent.spec.ts, which deletes a file and then depends on the
node's outputs (reproduced locally at the same line CI failed on).

Absence now forces a fresh list read instead of an immediate decision. A
selected path missing from a response is re-read once; it is only dropped
when a list fetched after that still omits it. A single late or out-of-order
response therefore cannot destroy the attachment, while a real delete still
clears it on the next read.

The effect also keys off dataUpdatedAt, since react-query's structural
sharing keeps the same array reference when a refetch returns equal data.