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

[jamadeo]

Looks good. For the untagged deserialization changes, do you think it's worth having tests such that we don't regress there? Is it sensitive to the ordering of the variants in the enum?

[DaleSeo]

Thanks for the review, @jamadeo! You're right that the untagged deserialization is sensitive to variant ordering. I've added a few regression tests.