Add documents to multiple collections without copying them

## Goal

Adding a document to a collection should feel like applying a tag. It should not copy the document or move it out of the page tree. The collection's trait gives the document its properties and makes it appear in that collection's views. A trait with no custom properties works as a simple tag.

Finish the existing multi-trait model so any document can carry one or more collection traits without changing its identity.

## Tasks

- [ ] Let users apply a collection to an existing document from either side, with search and autocomplete, and remove it again without removing the document.
- [ ] Show applied collections as searchable chips in the document properties area and item detail view.
- [ ] Keep a document's place in the page tree and its normal route when traits are added or removed.
- [ ] Combine properties from every assigned trait and make their source clear. Traits without custom properties should still work for grouping, search, and filters.
- [ ] Finish the save, validation, indexing, navigation, and lifecycle paths that still assume one owning trait. Applying a trait to a page must not make that page follow the collection's row cascade.
- [ ] Keep the title, content, icon, cover, links, relations, backlinks, and history attached to the one underlying document wherever it appears.

## Acceptance criteria

- A page can join one or more collections without leaving the page tree or becoming a duplicate.
- A document appears in every collection whose trait it carries, and each appearance opens the same underlying content.
- Properties from every assigned trait remain editable and clearly identify where they came from.
- A trait with no custom properties can group documents and be used in search or filters like a simple tag.
- Removing one collection leaves the document, its other memberships, and its links intact.
- Deleting a collection does not delete documents that belong elsewhere or have their own place in the page tree.

[Denormalize trait membership (terms/traits sidecar) #301](https://github.com/Automattic/cortext/issues/301) may optimize these queries, but it does not provide this workflow.

Start with the existing multi-trait model and compare it with “Denormalize trait membership (terms/traits sidecar) #301”; trace the save, validation, indexing, navigation, and lifecycle paths that assume one owning trait. Check the document properties area and item detail view entry points. Done means documents retain one identity and page-tree route while memberships, combined properties, search, filters, and removal behave as specified.

Written by the indexing model from the issue text.