Identify collections by ID when tagging apps

[johnworth]

Part of the Grouper removal. Draft until the service side lands — see the ordering note at the bottom.

Why

The community tag an app carries was minted here. collection.display_name was posted as an AVU value and apps stored it verbatim, which made the browser responsible for a storage format it has no business knowing, and tied every tag to a name that can change. Renaming a collection dropped its apps out of their own listing with nothing raised anywhere — that mechanism produced the 17 orphaned tag values (48 apps) currently in production.

Worse, it was about to get quieter: once terrain serves collections from the new groups service, display_name becomes an ordinary short name rather than a colon path, so this code would have started writing a different wrong value with no error anywhere.

What changed

Collections are identified by their ID on both the read and write paths, and the service composes the stored value:

• addAppToCollection / removeAppFromCollection send { community_ids: [...] } and DELETE /communities/:id instead of hand-built AVUs.
• getCollectionApps addresses the collection by ID.
• constants.METADATA.COMMUNITY_ATTR is deleted. The attribute name was only ever needed to build the AVU by hand, and that is exactly the coupling this removes.
• fullName / fullCollectionName are renamed to collectionId, rather than left carrying an ID under a name that says otherwise.

Testing

eslint, prettier, and the jest suite pass (the pre-commit hook runs all three). Three pre-existing failures in src/__tests__/dataSearch.js are unrelated and fail identically on main — verified by running that file on both.

Not yet exercised in a browser. The service side is verified end to end against a local cluster, but no browser has driven tagging an app into a collection and seeing it listed. That check is worth doing before this leaves draft, since it is what would catch a mismatch between what this sends and what terrain's schema accepts.

Ordering

The services accept both request shapes during the transition, so a stale bundle keeps working; that is what makes it safe for this to deploy on its own schedule rather than atomically with them. But the services have to land first:

• Add a community-list request schema for app community tags common-swagger-api#101 — the schema (needs a release cut)
• Read groups from the groups service, and tag apps with community IDs apps#303 — stores the ID, resolves legacy values
• Groups service client, behind the terrain.groups.backend toggle terrain#333 — passes the new shape through
• Deploy the groups service, the Grouper importer, and the apps/group-propagator cutover config deployments#86 — deployment and the one-off data migration