Fix #481: Add server name scoping support in DNS TXT records

[jalateras]

Summary

This PR implements optional server name scoping in DNS TXT records for authentication, allowing fine-grained permission control through an optional n=<pattern> parameter.

Problem

Currently, DNS TXT records provide wildcard access to ALL subdomains and path portions, making it impossible for DNS controllers to delegate limited namespaces to different teams. This was particularly problematic for enterprise scenarios like Microsoft's, where they need to scope permissions to specific prefixes (e.g., com.microsoft/team-foo-*).

Solution

Added support for an optional n=<pattern> parameter in DNS TXT records that allows specifying exact permission patterns. When not specified, the system maintains backward compatibility by defaulting to wildcard permissions.

Example usage:

v=MCPv1; k=ed25519; p=OHjrTGdvR2dFk1g5uTVNJ4/RxpDLYjVJTtTQlcwW0Jg=; n=com.example/team-foo-*

Changes

• Added DNSAuthRecord struct: New data structure to hold both public key and optional name pattern
• Updated TXT parsing: Modified regex to capture optional n=<pattern> parameter
• Enhanced permission building: buildPermissions() now uses specific patterns when provided
• Comprehensive test coverage: Added extensive tests for all scoping scenarios

Testing

• ✅ All existing tests pass (backward compatibility maintained)
• ✅ Added new test suite TestDNSAuthHandler_NamePatternScoping with 8 test cases
• ✅ Verified wildcard behavior when n= is not specified
• ✅ Tested multiple keys with different patterns
• ✅ Tested complex patterns with multiple path segments

Backward Compatibility

This change is fully backward compatible:

• Existing TXT records without n= parameter continue to work exactly as before
• Default behavior (wildcard permissions) is preserved when n= is not specified
• No changes required for existing deployments

Fixes #481

[jalateras]

squashed and pushed