docs: document cookie consent lifecycle event API

[chihsuan]

Fixes WOOA7S-1598

Proposed changes

• Document wp_consent_saved as the public Cookie Consent lifecycle event, including the stable event.detail.eventType and event.detail.choices shape.
• Document that consumers should gate scripts through the WP Consent API (wp_has_consent / wp_listen_for_consent_change) rather than a Cookie Consent-specific lifecycle event.
• Clarify that wp_consent_type_defined remains internal, and add Jest coverage for the public wp_consent_saved payload contract.

Related product discussion/links

• WOOA7S-1598
• WOOA7S-1603

Does this pull request change what data or activity we track or use?

No. This documents an existing lifecycle event and adds test coverage for its payload; it does not change tracking behavior or collected data.

Testing instructions

1. In a local WordPress site with the Cookie Consent package loaded by a consuming plugin and the WP Consent API plugin active, visit the front end with ?preview_cookie_consent=1.
2. In the browser console, add a listener for wp_consent_saved that logs event.detail.
3. Save a consent choice from the banner, such as accepting all or saving custom preferences.
4. Review projects/packages/cookie-consent/README.md, especially the Public APIs section.

• Expected: the console output includes an eventType matching the user action and choices keyed by Cookie Consent category keys such as analytics and advertising.
• Expected: the README directs category-state script gating to the WP Consent API and describes wp_consent_type_defined as internal.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• 🔴 Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[chihsuan]

Symphony AI is leaving this unchanged because this scoped GitHub session does not expose PR label management. The PR already includes the required description, testing instructions, data/privacy answer, and changelog entry, and it remains a draft for human review handoff.

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report

[chihsuan]

Symphony AI is leaving this unchanged because this is an automated coverage summary and does not request a code change. The PR intentionally keeps the implementation scope unchanged; validation and the added event-contract test coverage remain recorded in the Linear workpad.