Delete cleanup is fail-fast and can leave monitor-rootfs artifacts behind

[Yashbhu]

Description

When a container goes through block-based rootfs handling, urunc may extract runtime files (for example unikernel, initrd, urunc.json) under monitor-rootfs-related paths.
In the current delete path, directory cleanup is fail-fast:
if removing one cleanup target errors out, later targets are not attempted.

Reproduction (Linux host)

1. Create a container that takes the block-rootfs path and reaches monitor rootfs setup.
2. Before running urunc delete, make one cleanup target fail
3. Run urunc delete <container-id>.
4. Observe that delete stops after the first cleanup error and does not attempt remaining cleanup targets.
5. Check bundle/runtime paths and confirm leftover monitor-rootfs artifacts remain

Expected

Delete should attempt all cleanup targets, log per-path failures, and finish best-effort cleanup.

Actual

Cleanup exits early on the first removal error, leaving later targets unattempted.

[Yashbhu]

once approved please assign it to me @cmainas

[cmainas]

Hello @Yashbhu ,

indeed we fail-fast, but I am unable to reproduce the issue. However, even if these boot files remain in the system, they will get deleted form the shim, since it removes the whole bundle directory. For sanity though and just to be sure, your suggestion sounds valid and we can add it since it is not part of the hot path.