RHCLOUD-47238 Add Events and change notifications documentation

[josejulio]

Document Kessel's event system as CloudEvents 1.0 published to event topics. Explains what events are published (resource and relationship), event format, delivery guarantees (exactly-once, durability, ordering), and how events relate to the consistency model.

Written as pure Diataxis explanation focused on understanding the event system, not how to consume events (reserved for how-to guides).

All technical claims verified against source code (inventory-api proto definitions, outbox implementation).

[tylercreller]

I think the agent(s) got confused here because our eventing has changed and the old patterns were not fully removed. Using the CloudEvents spec was an artifact of the old eventing system. I looked at the current inventory-api source and our outbox events don't actually use or conform to CloudEvents 1.0. There's no CloudEvents SDK in go.mod, the ResourceEvent struct in model_legacy/outboxevents.go just happens to have fields named after CloudEvents attributes, and the source field is permanently empty with a TODO that was never implemented. There's also an e2e test (kafkaconsumer_test.go) that validates against a schema described as "compatible with CloudEvents" which is likely what reinforced this, but that test is just validating the shape of our custom payload, not actual spec compliance. We're essentially just pushing a resource as the payload to the Kafka topic. I would say we should err on the side of not calling out CloudEvents.

[tylercreller]

We are not technically exactly-once, we are at-least-once processing. The consumer uses manual offset commits with a modulo of 10 (commitModulo: 10 in options.go:36). If the consumer crashes between processing a message and committing, that message will be reprocessed. The AlreadyExists handling in CreateTuple (line 518) shows the system is designed to handle duplicates, which is an at-least-once pattern with idempotency.