Clarify seed predictability and CRE-vs-VRF guidance in the randomness guides

[ejacquier]

Summary

• Adds a Seed predictability and trigger choice section to both the TS and Go "Using Randomness in Workflows" guides, explaining that the per-execution seed has no secret mixed in and breaking down predictability by trigger type (Cron: publicly known schedule; EVM Log: as safe as the chain's block production; HTTP: safe only as long as the authorizedKeys signing key stays private).
• Adds a Choosing between CRE randomness and Chainlink VRF section giving concrete guidance on which use cases fit CRE's consensus-based randomness (operational/non-adversarial flows) versus when to use VRF (public draws with direct economic value, where a cryptographic proof of fairness is required).
• Notes a commit-reveal mitigation for teams that need to stay adversarial-resistant on an otherwise grindable/front-runnable trigger.
• Clarifies that CRE's onchain result is accepted via a valid DON signature (attestation of consensus), not a mathematical correctness proof the way VRF's is.
• Updates the TL;DR aside and FAQ answer in both guides to point to the new sections.

Why

Today's guides describe how to generate randomness but don't tell users how predictable that randomness actually is, or when CRE's trust model is/isn't appropriate for a given use case. This fills that gap so users can make an informed choice up front rather than discovering the limitation after shipping an adversarial-facing draw.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
documentation	Ready	Preview	Aug 17, 2026 4:54pm

[github-actions]

👋 ejacquier, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!