Add optional event provenance and tamper-evidence guidance (#315)

[MarkovianProtocol]

Adds an optional, informational companion document on event provenance, as invited in #315.

Two properties, kept distinct:

• Part 1 — authenticity and integrity, via DSSE. Who emitted the event, and whether its payload was altered. Reuses the DSSE work already adopted in CloudEvents.
• Part 2 — existence over time, via an optional hash commitment. A signature proves who, not when: a key holder can re-sign a back-dated or quietly reissued event at any time. Committing the event's RFC 8785 (JCS) SHA-256 digest to a timeline outside the emitter's control closes that gap, and survives key rotation, key loss, and emitter compromise after the anchor time.

Per the discussion in #315, this is deliberately mechanism-agnostic. The document names the class of anchors — RFC 3161 timestamp authorities, append-only transparency logs, public blockchain inclusion — without endorsing one, and states explicitly that the choice of anchor is out of scope. The only thing CDEvents tooling needs to agree on is the commitment itself: RFC 8785 canonicalization plus SHA-256.

Scope of this PR

• New file event-provenance.md (root level, matching existing document convention).
• One entry in README.md under the key assets list.
• Spellcheck wordlist additions for the acronyms used (DSSE, JCS, PAE, SLSA, RFC, SHA, Merkle, and related).
• No schema changes, no changes to spec.md or any event definition. Nothing here is required of an implementer.

Worked example. A runnable end-to-end example lives outside this repository at MarkovianProtocol/cdevents-provenance so CDEvents takes no dependency on it: a real dev.cdevents.artifact.published.0.3.0 event validated against the published v0.5.1 schema, its JCS canonical bytes, a DSSE envelope, the commitment, and a verifier demonstrating genuine artifacts passing both checks and tampered ones failing both. Happy to vendor it under tools/ or conformance/ instead if the group prefers it in-tree.

Venue, wording, and which anchor mechanisms to list are all open to the group's preference — happy to walk through it at the SIG.

Closes #315