RS posts/pages: trashing fails on WP.com sites

### Summary

Trashing a post or page from the wordpress-rs list in Jetpack Android fails on WordPress.com-hosted sites. The user sees a toast reading "Failed to trash post" and the post stays put. The request is rejected by the [WP.com](http://wp.com/) REST proxy before it reaches any trash logic.

### Steps to reproduce

* Enable `android_wp_rs_wpcom` so a [WP.com](http://wp.com/) site routes to the rs posts screen (`PostRsListActivity`)
* Open Posts, pick Trash from a post's overflow menu, confirm
* Toast: "Failed to trash post"

Observed on a Jetpack debug build, 2026-09-10, against a WordPress.com-hosted site.

### The failing request

```
DELETE https://public-api.wordpress.com/wp/v2/sites//posts/?force=false
→ 400
{"code":"rest_invalid_param","message":"Invalid parameter(s): force","data":{"status":400}}
```

Surfaced as `uniffi.wp_mobile.FetchException$Api wrapping WpApiException$WpException` with `errorCode=WpErrorCode$InvalidParam`, logged under WordPress-POSTS as "Trash failed".

### Cause

force=false is WP core's default for DELETE /wp/v2/posts/, so sending it explicitly is redundant. Core accepts it; the [WP.com](http://wp.com/) public-api.wordpress.com/wp/v2/ proxy rejects it as an invalid parameter.

The app does not choose this. PostRsListViewModel.trashPost calls postService.trashPost(PostEndpointType.Posts, postId) — that signature has no force argument, and force appears nowhere under ui/postsrs. wordpress-rs appends the parameter itself to distinguish trash from deletePostPermanently, which sends force=true.

Start with PostRsListViewModel.trashPost and follow postService.trashPost into the wordpress-rs request construction; the issue identifies the ui/postsrs area and the force parameter behavior to inspect. Confirm that trashing a post no longer sends force=false to the WP.com proxy while permanent deletion continues to send force=true, then verify the reported request succeeds.

Written by the indexing model from the issue text.