chore: add #[non_exhaustive] to remaining public structs

[DaleSeo]

Motivation and Context

PR #715 began the effort to mark public types as #[non_exhaustive] ahead of the 1.0 release, but missed several structs and enums across transport, service, handler, auth, and task_manager modules. Without this attribute, any new field or variant addition is a semver-breaking change for downstream consumers.

To prevent this class of omission from recurring, this PR also enables clippy::exhaustive_structs and clippy::exhaustive_enums as warn in Cargo.toml. Types that are intentionally exhaustive (unit structs, newtype wrappers, and protocol-spec model types) are annotated with #[allow]. Any new public struct or enum added without #[non_exhaustive] will now produce a Clippy warning.

How Has This Been Tested?

All the existing tests have passed.

Breaking Changes

Yes. Adding #[non_exhaustive] to structs that previously had all public fields is technically a semver-breaking change. However, this is the same intentional tradeoff made in #715: accepting a one-time break now to prevent repeated breaks every time a field is added in the future. Most consumers already use Default or constructor methods, so the practical impact should be limited. For OAuthClientConfig, which had no constructor, a new() builder was added.

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