Make Edge Cookie identity pluggable and opt-in #778

User story

As a deployer, I want to choose how the Edge Cookie identity is derived, or run with none, so that identity is a deliberate configuration choice rather than a fixed behavior.

Description

The Edge Cookie identity is currently hard-wired as an HMAC-SHA256 value over the client IP. Introduce an EdgeCookieModule interface selected by configuration, with a built-in HMAC module that preserves today's behavior. There is no default selection, so with no module chosen Trusted Server runs statelessly. Trusted Server stays neutral on policy here, and the deployer decides whether to derive an identity and how.

Done when

• An EdgeCookieModule interface is selected by [ec] module, and a module from a crate is named by its crate folder.
• A built-in HMAC module reproduces the current identifier.
• With no module selected, no Edge Cookie is created and the request proceeds.
• Identifier comparison is a module operation, so a module whose identifiers wrap the same payload in different envelopes can compare by payload.
• A module can return response headers (for example to request more client evidence on a later request).

References

• Part of Pluggable, competition-neutral modules with a technical permission model #777. Implemented by the Edge Cookie module seam (Add a pluggable Edge Cookie module seam with the built-in HMAC module #1343), with the client-set value path (Add the client-set Edge Cookie value path #1346) and the guides (Add the module documentation set and finish the decomposition #1347). The design is in Add the integration seam design specs #1342. The earlier discussion of each is on Add a pluggable Edge Cookie module seam with the built-in HMAC module #1043, Add the client-set Edge Cookie value path #1046, Add the module documentation set and finish the decomposition #1047 and Add the integration seam design specs #1084.
• Related: Implement Edge Cookie (EC) key system (Phase 2) #712 (Edge Cookie key system, Phase 2).