wpscloudsvr crashes on every launch (SIGSEGV in libqingbangong.so)

## Summary

`wpscloudsvr` (WPS's background cloud-sync helper process) segfaults with SIGSEGV inside `addons/qing/libqingbangong.so`, at the exact same code offset, every single time any WPS Office module is launched. The crash is 100% reproducible and independent of account/login state — it still occurs identically even against a completely fresh, newly-generated local profile with no prior cloud account history.

The main application (tested with WPS Spreadsheets and WPS PDF) continues to function normally; only the background cloud-sync helper crashes. No cloud sync is configured or in use on this system.

## Environment

- **App:** WPS Office (Flatpak), `com.wps.Office`, version `11.1.0.11723`, branch `stable`, origin `flathub`
- **Runtime:** `org.freedesktop.Platform/x86_64/25.08`
- **Install type:** system-wide Flatpak
- **OS:** Ubuntu 26.04 "Resolute Raccoon", kernel `7.0.0-31-generic`, x86_64
- **Desktop:** KDE Plasma (Wayland)
- **GPU:** NVIDIA GeForce RTX 5060 Ti, driver 595.91.07

## Steps to Reproduce

1. Launch any WPS Office module (observed with both WPS Spreadsheets `et` and WPS PDF `wpspdf`).
2. Within 1–3 seconds, `wpscloudsvr` crashes with SIGSEGV.
3. Repeats on every launch, regardless of document content or account state.

## Expected Behavior

`wpscloudsvr` starts and runs normally in the background (or, if cloud sync is genuinely unneeded/unconfigured, does not crash while idle).

## Actual Behavior

`wpscloudsvr` segfaults immediately on every launch.

## Crash Details

Kernel log (identical offset across every occurrence, multiple dates/PIDs):
```
kernel: wpscloudsvr[]: segfault at 17a ip 00007xxxxxxxx1a2 sp 00007xxxxxxxxxx0 error 6 in libqingbangong.so[c431a2,+1aef000] likely on CPU (core , socket 0)
```

Coredump backtrace (via `coredumpctl`), crashing frame:
```
#0 0x00007xxxxxxxx1a2 n/a (/app/extra/wps-office/office6/addons/qing/libqingbangong.so + 0xc431a2)
```

Loaded modules at crash time include (non-exhaustive): `libqingbangong.so`, `libkqingaccountsdk.so`, `libwpscloudsvrimp.so`, `libqingipc.so` — all part of WPS's "Qing" cloud/account SDK addon.

## Occurrences observed

| Date/Time | PID | Trigger |
|---|---|---|
| 2026-09-09 15:05:58 | 24808 | Launched WPS Spreadsheets (`et`) |
| 2026-09-10 09:45:51 | 16548 | Launched WPS PDF |
| 2026-09-10 10:34:15 | 12967 | Launched WPS Spreadsheets (`et`) |
| 2026-09-10 10:35:00 | 13155 | Launched WPS Spreadsheets (`et`) |
| 2026-09-10 10:37:09 | 13464 | Launched WPS Spreadsheets (`et`) |
| 2026-09-10 11:03:34 | 17894 | Launched WPS Spreadsheets (`et`), **after wiping all local account/qing cache** |
| (earlier, less frequent) 2026-05-20, 2026-06-03 | — | Same signature, same crashing library |

## Troubleshooting already performed (ruled out)

- **Confirmed not a stale/corrupted cloud-login cache.** Backed up and removed `~/.var/app/com.wps.Office/data/Kingsoft/account/` and `.../qing/` entirely, forcing WPS to regenerate a completely fresh local profile. The crash reproduced identically (same offset `0xc431a2`) on the very next launch against the fresh state.
- **Confirmed no cloud sync is configured.** `WPSCloud.conf` has every sync/upload feature flag (`SendBy`, `UploadSync`, `fileTransfer`, `DesktopSync`, `kicUploadSyncSwitch`, etc.) set to `false`, and the local `WPS Cloud Files/userdata/AllUsers` folder is empty — no synced files exist.
- **Confirmed already on the latest available version.** `flatpak update --dry-run` / `flatpak remote-ls --updates` show no pending update for `com.wps.Office` (already at `11.1.0.11723`, latest on Flathub).
- **Not fatal to the app.** The parent WPS module (Spreadsheets/PDF) continues running normally after `wpscloudsvr` crashes.

## Attachments available on request

- `.zst` coredump files under `/var/lib/systemd/coredump/core.wpscloudsvr.*` (one per occurrence above).
- Full `coredumpctl info ` output for any of the PIDs listed above.

Start with the listed coredumpctl outputs and the reproducibility steps for wpscloudsvr, including the fresh-profile test. Review whether the crash can be addressed in the Flatpak packaging or must be reported upstream to WPS; done should mean the helper no longer crashes or maintainers document the upstream limitation.

Written by the indexing model from the issue text.