macOS: client silently killed by cache_delete (0xBADDD15C), no crash report, must be manually relaunched

# Nextcloud desktop client silently killed by macOS `cache_delete` daemon (no crash report, no client error)

**Environment**

- macOS 26.6.1 (Build 25G76) — Mac Studio M4 Max
- Nextcloud desktop client **34.0.1** (build 34.0.1.0), Qt 6.10.2, OpenSSL 3.6.3
- Server: Nextcloud 34.0.2.1 (self-hosted)
- Client runs as a login item, menu-bar app (`LSUIElement=1`), syncing an external APFS volume
- Client is **not** sandboxed-crashing: no crash report is ever produced, and the client's own log ends cleanly

## Summary

The Nextcloud desktop client is being **silently terminated by the macOS system daemon `cache_delete`** (cache eviction for app container caches). The app disappears from the menu bar with:

- no crash report (no `.ips` in `~/Library/Logs/DiagnosticReports`),
- no error in the client's own sync log (last lines: `SyncEngine finished without problem.` / `Sync state changed ... "Success"`),
- no jetsam/memory-kill entry.

This is **not** an app crash — the system kills the process. On our machine it happens roughly once every 1–2 days of uptime. The client has to be manually relaunched each time; it does not come back on its own.

## Evidence from unified log (macOS)

At the moment of death (2026-08-18 15:12:35, process PID 745):

```
15:12:35.156 runningboardd: Received termination request from [osservice:468]
on >
with context

15:12:35.243 runningboardd: [app:745] Terminating with context:

15:12:35.264 ControlCenter: [app<...com.nextcloud.desktopclient...>:745] Process exited:
>
```

`0xBADDD15C` is the RBS termination code for `CacheDeleteAppContainerCaches` — i.e. the `cache_delete` daemon asked RunningBoard to terminate the app so it could purge the app-container caches. The termination context reports `maxTerminationResistance:NonInteractive`, which is why the system considers the app expendable.

`cache_delete` runs system-wide; at the same time it also terminated other apps (Shortcuts widgets, wallpaper.agent, Weather, Safari, QLMarkdown, …) — Nextcloud is collateral damage, not a targeted kill.

## Timeline of repeated silent deaths (60 days, 4 process instances)

| Instance (PID) | Started | Died | Lifetime |
|---|---|---|---|
| 24175 | 2026-08-15 00:18 | 2026-08-16 18:18 | ~42 h |
| 11466 | 2026-08-17 10:40 | 2026-08-17 14:53 | (short, logout) |
| 745 | 2026-08-17 14:54 | **2026-08-18 15:12** (cache_delete, logged) | ~24 h |
| 5165 | 2026-08-18 16:15 | (manual relaunch, still running) | — |

The client's own log (`Nextcloud_sync.log`) shows no error before death — the final sync run completes successfully and then the process is gone.

## Impact

- Sync silently stops; user notices only when the menu-bar icon is missing.
- No crash report, no client-side error → hard to notice and hard to automate around.
- The client is a login item but macOS does **not** relaunch it after a `cache_delete` termination.

## Expected behaviour

A background sync client should not be killed without warning by cache eviction, or at least should be restarted automatically afterwards.

## Questions / suggestions for the maintainers

1. Why does the app register as `maxTerminationResistance:NonInteractive`? Menu-bar apps that need to keep running (e.g. sync clients) should opt into a higher termination resistance (e.g. `NSDisableAutomaticTermination` / appropriate `RBSTerminateContext` handling).
2. Should the client register a `cache_delete` purge handler so the system can evict caches *without* killing the process?
3. Could the client auto-relaunch when terminated by the system (like a proper background agent / `SMAppService` daemon with `KeepAlive`), instead of requiring a manual start?
4. The app container caches involved are tiny (~228 KB QML cache) — killing the process to purge them seems disproportionate; a purge handler would avoid the kill entirely.

## Reproduction

Not easily reproducible on demand — `cache_delete` runs opportunistically (in our case under memory pressure / periodic purges). But on any macOS system where the client runs as a menu-bar app it can be observed with:

```
log show --predicate 'eventMessage CONTAINS "com.nextcloud.desktopclient" && eventMessage CONTAINS "cache_delete"' --last 7d
```

If the process died this way, you'll see the `0xBADDD15C` / `CacheDeleteAppContainerCaches` termination above.

Start by running the supplied `log show` predicate and confirm the `0xBADDD15C` termination pattern on macOS. The payload names no source files or tests; first investigate the client's macOS lifecycle integration and determine whether maintainers want cache-purge resistance or automatic relaunch, then verify the chosen behavior under system cache eviction.

Written by the indexing model from the issue text.