feat: add Default and constructors to ServerSseMessage

[erenatas]

Motivation and Context

ServerSseMessage is #[non_exhaustive] but has no public constructor, Default impl, or builder, making it impossible for downstream SessionManager implementations to produce these values without unsafe.

This change adds #[derive(Default)] and two named constructors covering the common patterns:

• ServerSseMessage::new(event_id, message) — JSON-RPC content with
  an event ID
• ServerSseMessage::priming(event_id, retry) — priming event per
  SEP-1699
  Update all internal call sites in tower.rs and local.rs to use the new API.

How Has This Been Tested?

Tested in an rmcp based project. Pre-existing tests in tower.rs and local.rs continue to pass — these exercise the SSE stream paths that now use the new constructors.

Note: the existing http_header test module on main has a pre-existing compilation error (references a renamed function extract_scope_from_header); this is unrelated to this change.

Breaking Changes

None. This is a purely additive change:

Default is a new trait impl on an existing public type.
new() and priming() are new inherent methods.
No existing API surface is modified or removed.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[DaleSeo]

Can we add lightweight tests that assert field values for ServerSseMessage::new, ServerSseMessage::priming and Default? It would guard against accidental regressions if the type or helpers evolve.

[erenatas]

Can we add lightweight tests that assert field values for ServerSseMessage::new, ServerSseMessage::priming and Default? It would guard against accidental regressions if the type or helpers evolve.

Yes, thank you for the suggestion. On it

[erenatas]

I updated with basic tests, if you won't mind I fixed couple issues with tests that prevented me to run cargo test --all-features (--workspace still doesn't work, for another PR perhaps). Let me know if its a problem and I will revert my changes. Thanks!