An events collection cannot be wildcarded

An entity event is published on <component>.v1.<collection>_events.<action>, for example iam.v1.roles_events.created. A subscriber that wants every event of every component cannot say so: a NATS wildcard is a whole token, so *_events is the literal token *_events and matches nothing.

$ # subscribed, accepted, and heard nothing
SUB ores.dev.example.*.v1.*_events.> 1
+OK
$ # a literal, matching one subject that will never exist
PUB ores.dev.example.iam.v1.roles_events.created
# delivered to nobody

The first version of the change feed subscribed with that pattern. The server accepts it and delivers nothing, so the stream was silent with no error anywhere, and only a live run found it.

The feed now subscribes *.v1.> and filters the collection in the parse. That is correct and costs a copy of every versioned request in the system, which no one chose deliberately.

The events namespace is not addressable as a namespace. Two candidate spellings make it so:

• <component>.v1.events.<collection>.<action>, an explicit token. One subscription *.v1.events.> hears every event and no request, the wildcard is a whole token, and the collection is a token of its own rather than a suffix.
• events.<component>.<collection>.<action>, a namespace in front. Same effect, and it puts the events outside a component's versioning, which may be wrong.

Either way every entity_event_traits<>::subject_prefix changes, which is the generated-or-hand-written span to measure first: subject_prefix appears in projects/ores.<component>/api/include/ores.<component>.api/eventing/*.hpp, and the subject-conformance check holds the shape.

• projects/ores.http/core/include/ores.http.core/stream/change_feed.hpp, where the pattern and the reason sit beside each other.
• Stream the changes as they happen, whose feed found this.

• A merge took an old tree over two merged increments, which deleted the feed before the live run could have found this.