Confirm and guard legacy site rename in the DA UI

At the org level, the browse UI treats a site as an ordinary folder. Rename submits:

```text
POST /move/{org}/{site}
```

The destination is the new site root.

There is no confirmation. Submitting the inline rename starts the move. The UI also changes its local name and path before the request succeeds.

The current backend uses a tree copy followed by source deletion. It has no rollback or lock. PR adobe/da-admin#303 causes version and audit history to stay under the old site prefix, while the request can still return 204.

Site rename is a valid legacy DA use case. It needs a separate UI flow from folder rename.

This issue covers legacy DA sites. HLX6 site rename needs a separate migration flow.

## Proposed behavior

Keep Rename for a legacy site selected at the org level.

Before sending the request, show a confirmation with:

- the old and new site names
- a warning that the operation moves the whole DA site
- the 1000 stored-object limit from adobe/da-admin#305
- the old `content.da.live` URL that connected EDS projects must update

Suggested text:

> Rename `{oldSite}` to `{newSite}`?
>
> This moves the site's content, versions, and audit history. Sites with more than 1000 stored objects cannot be renamed here.
>
> Update any EDS project that uses `https://content.da.live/{org}/{oldSite}/`.

Use `Rename site` and `Cancel` actions.

Do not crawl the site in the client. The delete UI's 1000-item guard counts visible files by crawling every folder and every continuation page. The backend rule in #305 counts stored objects, including hidden storage. The backend is the authoritative gate.

Handle the backend response by error code:

- `site_rename_too_large`: show the limit and keep the old site name
- `site_destination_exists`: show that the new site already exists
- `partial_failure`: tell the user that the rename did not complete and a refresh is required
- 204: update the item path, clear the selection, and dispatch `renamecompleted`

Do not change the local item name or path before a 204 response.

Hide Cut for a site selected at the org level. Cut and Paste reaches the same site-root move without the rename confirmation. Folder Cut remains unchanged.

This UI change depends on the backend contract in adobe/da-admin#305.

Start in the browse UI's org-level site rename and Cut/Paste flows, tracing POST /move/{org}/{site} and the backend contract in adobe/da-admin#305. Verify the confirmation, response-code handling, and delayed local update for 204, while folder behavior remains unchanged. Done means site Cut is hidden at org level and renamecompleted is dispatched after a successful rename.

Written by the indexing model from the issue text.