Use a single @ for the Contents view resource routes

[sneridagh]

Stacked on #265. Merge that first, then retarget this one to main.

Problem

The convention: Aurora resource routes use a single @, like the REST API endpoints and the cmsui resources (@search, @objectBrowserWidget, @queryStringOptions). Views (routes that render a page) use @@, like @@edit, @@add and @@contents.

@plone/contents registered its action resource routes with @@, as if they were views: /@@contents/@@delete, @@upload, @@rename, @@workflow, @@tags, @@properties, @@order and @@paste. They only return data or handle an action, so they're resources. The convention wasn't written down anywhere.

Changes

• Routes: the actions become /@@contents/@delete, /@@contents/@upload, /@@contents/@rename, /@@contents/@workflow, /@@contents/@tags, /@@contents/@properties, /@@contents/@order and /@@contents/@paste. As discussed below, they stay nested in the view's path, so they don't collide with other add-ons' resources. They're registered apart from the Contents layout, which their requests never rendered. Their single-@ segment makes them resources, so the root middleware skips the content for them by Let resource routes skip the root content middleware #265's convention, and their skipContent flags go away. The /* splat is kept, since paste uses it for the target folder.
• Callers: the eight modals and ContentsTable use the new URLs.
• Convention: written down in the routes how-to (docs/how-to-guides/routes.md) and in the AGENTS.md of cmsui and contents, including nesting a view's own resources in its path, and that the root middleware skips the content for resource routes.
• News: a breaking fragment in @plone/contents, for any code that calls the old URLs, and a documentation fragment in the app.

Tests

The Contents actions had no acceptance tests. The new packages/contents/acceptance/tests/contents-actions.test.ts covers:

• deleting an item (checked after a reload, since the listing drops the row right away);
• renaming an item;
• loading the workflow transitions of the selected items.

All three fail when the modals call URLs the routes don't match. The contents acceptance suite (7 tests) and contents vitest (33) pass. check:ts for @plone/contents reports the same 13 errors as on main, all in files this PR doesn't touch.

[sneridagh]

@pnicolli uncertain about the convention with this one. Since they are resource (actions) routes, should be rooted to @@contents? And then add another @@ prefix? It feels to me weird... I made this PR with the convention:

@contents/delete... but I am not sure. Meaning "resource action route" + "variant". What do you think?

The alternative could be @@contents/delete might lead to content id collisions, of course...

[pnicolli]

Yeah I agree that what we have now is not optimal, I think it slipped in with the wrong convention in the years in the making of this package. I think the convention should be:

• cmsui routes have @@ as a prefix
• resource routes have @ as a prefix

This way we can avoid conflicts and keep consistency (also with how the restapi looks like, as an added bonus).

The reasoning behind nesting of dedicated resource routes here (i.e. /@@contents/@delete) is to avoid conflicts with other add-ons since this delete is specific for this use case. One could argue it can be made generic and global, but I'm not super sold on this because I don't really want to maintain a restapi replica.

[sneridagh]

@pnicolli right! implemented!