Harden paste process plugin pipeline and cap max non-file paste size input

[guiyanakuang]

Follow-up hardening after #4698 / #4699.

Problems

1. A throwing plugin leaves the paste row stuck in LOADING state. The plugin loop in PasteReleaseService.releaseLocalPasteData has no exception isolation. For example, FilesToImagesPlugin throws IllegalStateException when a file move fails, which aborts the whole loop: the row is never marked deleted nor updated to loaded, so it stays invisible and unrecoverable.

2. The order of pasteProcessPlugins is load-bearing but undocumented. Several invariants are easy to break silently, e.g. DiscardOversizedNonFilePlugin must precede DistinctPlugin (otherwise FirstPlugin may keep an oversized first item and clear a smaller surviving variant from disk before the oversized one is discarded), generate plugins must never emit items larger than their already-size-checked sources, and SortPlugin must be last because the first item determines the row's type/hash/search content. Mobile assembles the same commonMain plugins and must keep the same invariants.

3. maxNonFilePasteSize accepts any positive value. Without an upper bound, the setting can effectively disable the oversized-item guard introduced in Discard oversized non-file paste items to prevent huge database rows #4698.

Changes

1. Wrap each plugin invocation in runCatching: on failure, log a warning and continue with the current items instead of aborting the release.
2. Document the plugin order invariants at the desktop plugin list assembly site.
3. Cap the settings Counter input for maxNonFilePasteSize to 1..64 MB.