[pdwaldrop]

Description

Deleting one large folder showed no progress until its last entry was gone. DeleteProgress counts whole top-level items, so a single folder with hundreds of thousands of files stayed at 0% for the whole deletion and looked frozen, as #1930 describes.

The delete workers now count each file, symlink and folder they remove (a counter on the Deadline every delete job already carries, so no new parameter through the copy, replace and merge callers). While a permanent deletion runs, run_deletion_in reports that count every 250 ms, only when it changed, as a new OperationEvent::DeleteEntriesRemoved. The browser forwards it as BrowserEvent::DeletionEntriesRemoved for both the modal and the docked card, and when one item is being deleted the progress view pulses and shows "N items deleted", the same presentation Empty Trash uses. With several items the item percentage stays, since the count would only flicker against it. No new strings: it uses the existing "%{items} deleted" and item count text.

Not changed: the first symptom in the issue, the confirmation dialog's "Calculating total size…" step that can run for up to five minutes, is separate and untouched. A deletion that moves items to Trash is a rename and reports no count.

Visual evidence

N/A: no layout change. The progress text and pulsing bar now update while one folder is deleted.

How to test

1. Create a folder with many files, for example mkdir big && cd big && seq 1 200000 | xargs touch.
2. In Strata select the folder and press Shift+Delete, then confirm.

Expected result: the progress shows a pulsing bar and a running "N items deleted" count instead of staying at 0%. Before this change it showed 0% until the folder was gone.

Covered by workers_count_every_file_symlink_and_folder_they_remove, removed_entries_are_reported_when_they_change_and_stop_with_the_reporter, removed_entry_counts_reach_observers_only_from_the_current_deletion and one_deleted_folder_counts_the_entries_removed_but_several_items_keep_their_percent. Disabling the worker count or the progress handler makes the matching test fail. The local_operations, app, services and progress suites and the delete, trash and undo QA scenarios pass. I did not time a real 300,000-file deletion.

Related issue

Part of #1930

[l0gicgate]

Review pass for merge:

• Merged main (44bfeab) into the branch; no conflicts.
• Hungarian catalog (fix(i18n)): main fails i18n::catalog_tests::catalogs_cover_all_languages_and_preserve_interpolation because feat(i18n): add Hungarian locale #1918 (Hungarian) and feat(browser): open unreadable local folders as administrator #1837 (administrator strings) landed independently and the push workflow skips tests. Added the nine missing Hungarian entries so this PR's CI can go green. Not related to this change otherwise.
• Reporter test: removed_entries_are_reported_when_they_change_and_stop_with_the_reporter now waits for the reporter tick (5 s cap) instead of a fixed 40 ms, so a loaded CI runner cannot turn it flaky. Three doc comments tightened.

The deletion change itself is sound: Deadline already travels with every delete job so the counter needs no new plumbing, the reporter is dropped before run_deletion_in returns so no late DeleteEntriesRemoved can follow the terminal event, and stale-request filtering covers the new event through the existing callback guard.

Manual check in the QA container (600,000 files in one folder, Shift+Delete): the docked card switched from 0% to a pulsing bar with “270,325 items deleted” about 250 ms after unlinking began, then “Complete · 100%”. One observation outside this PR: on that fixture the card showed 0% for about 1.5 s before any file was unlinked (the file count on disk stayed at 600,000 until ~2.5 s after confirming), so there is still a pre-removal phase the issue's “appears stuck” complaint may partly come from. Worth a separate look under #1930.

Local verification: full pinned ./scripts/quality.sh all (3665 passed; the single failure was the pre-existing Hungarian catalog test, fixed above and rerun green with i18n::), targeted local_operations::tests::deletion, app::browser::tests::{operation_events,operations,background_operations,undo,relocation::operation_updates}, ui::browser::progress::tests, and the delete/trash/undo QA scenarios (17 runs) via ./scripts/qa.sh; fmt and clippy phases rerun on the final code.

[l0gicgate]

CI note: the first run's shard 3 failed in merge_never_overwrites_an_entry_created_during_the_merge (the nested alias rename was reported under the parent's pre-rename name). It passed 15 single runs and 3 full local_operations::tests::merge module runs locally, is untouched by this change, and passed on the full rerun, so I am treating it as a pre-existing race in the merge report path. All checks are green on 9638bdc.