drop_database replicated: true — database reappears after refresh; second call drops a node from the replicated array

Two bugs observed when `drop_database` is called with `replicated: true` in a cluster where one instance is still in "Cloning" status:

## Bug 1: Database reappears after refresh

After a successful `drop_database replicated: true`, refreshing the page shows the database again. The database still exists on the cloning instance, and the UI re-displays it on refresh. Expected: either prevent the drop on a partially-joined cluster (with a clear error), or mark the database as "pending delete" and suppress it from the UI.

## Bug 2: Second drop returns only one node in replicated array

After the first drop fails on the cloning instance, calling `drop_database replicated: true` again returns a `replicated` array with **only one node** (the successful one), as if the second node no longer exists:

```json
{
"message": "successfully deleted 'data'",
"replicated": [
{ "message": "successfully deleted 'data'", "requestId": 1, "node": "[redacted-node]" }
]
}
```

Expected: both nodes appear in the replicated array (one success, one with the appropriate error/status).

## Acceptance criteria

- A `drop_database replicated: true` on a partially-joined cluster either:
- Succeeds on the joined nodes and returns per-node status for all nodes (including the cloning one), OR
- Fails early with a clear error saying the cluster isn't fully joined.
- The second call always returns all registered cluster nodes in the `replicated` array.
- Behavior is consistent with other `replicated: true` operations.

---

Jira fields: **Feature Type:** Tech Debt · **Business Impact:** Customer Experience (GRR/NPS) *(both suggested)*

🤖 Filed by Claude on behalf of Kris.