CLI: remove page recycles silently, and the CLI cannot inspect, restore, or purge the recycle bin

Nobody has claimed this yet.

### Search first

- [x] I searched and no similar issues were found

### What Happened?

Using the `logseq` CLI on a DB graph, I removed a page and later found its name permanently unusable from the CLI, with no CLI-side way to diagnose or fix it.

`logseq remove page` soft-deletes (recycles) the page, but:

1. It reports plain success — `{"status":"ok","data":{"result":true}}` — with no indication that the page was recycled rather than deleted.
2. Any later `upsert block --content "... [[Name]]"` fails with `{"code":"recycled-page","message":"page is recycled"}`. `upsert page --page "Name"` fails the same way, so the name cannot be reclaimed.
3. This happens **even when a live page with the same `:block/name` still exists**.
4. The CLI offers no way to list, restore, or permanently delete recycled entities. `remove page --help` exposes only `--id` and `--page`. The only way I found to see what was in the recycle bin was a raw Datascript query on `:logseq.property/deleted-at`.
5. The error message does not mention that a recycle bin exists, where it is, that entries are garbage collected after 30 days, or how to clear it.

The `Recycle` page itself has `logseq.property/hide?: true` and `built-in?: true`, so it is not discoverable through search or All pages — it is only reachable via the `⋯` toolbar menu in the GUI. A CLI-only user therefore has no path to recovery at all.

### Reproduce the Bug

```
logseq upsert page --graph G --page "Test Page"
logseq remove page --graph G --page "Test Page"
# → {"status":"ok","data":{"result":true}} (no mention of recycling)

logseq upsert block --graph G --target-page "Host" --content 'link: [[Test Page]]'
# → {"status":"error","error":{"code":"recycled-page","message":"page is recycled"}}

logseq upsert page --graph G --page "Test Page"
# → same error; the name cannot be reclaimed from the CLI
```

Same outcome when a live homonym still exists. To reproduce that case: create the page, then `upsert tag` with the same name (two live entities with the same `:block/name`, allowed because tag sets differ), remove one by `--id`, then link by name — still `recycled-page`.

### Expected Behavior

- `remove page` should report that the page was **recycled**, not just return success.
- The `recycled-page` error should be actionable: state that the entity is in the recycle bin, and how to restore or purge it.
- The CLI should expose the recycle bin, e.g. `logseq list recycled`, `logseq remove page --purge`, `logseq restore page`.

Points 1 and 2 are the minimum. The core problem is that the CLI can create a state that it can neither observe nor undo.

### Screenshots

_No response_

### Desktop or Mobile Platform Information

OS: Windows 11 Home, 10.0.26200
Logseq DB 2.0.1
CLI build 2026-07-13, revision b09316a

### Additional Context

Related but distinct: logseq/db-test#1106 touches the same `ldb/recycled?` check in the page-creation path, from the GUI side.

For reference, these CLI workarounds do work — only the literal `[[Name]]` form is blocked:

```
logseq upsert block --graph G --target-id --content '...'
logseq upsert block --graph G --target-page "Host" --content "... [[]]"
```

### Are you willing to submit a PR? If you know how to fix the bug.

- [ ] I'm willing to submit a PR (Thank you!)

Start with the `remove page`, `upsert page`, and `upsert block` CLI entry points, then inspect the mentioned `ldb/recycled?` check and the `recycled-page` error path. Reproduce the commands in the issue and verify that recycling is reported clearly and that the CLI provides the requested way to inspect or undo it.

Written by the indexing model from the issue text.