fix: reject unknown recipient BaseType in BuildPolicyJson

[dobby-coder]

Summary

BuildPolicyJson only handled BaseType == "email" and "emailDomain"; any other value silently produced a policy entry with an empty con (only the recipient's Extras). Today this is unreachable but represents a footgun — adding a new builder without updating BuildPolicyJson would yield broken/permissive encryption policies.

This PR converts BaseType from a stringly-typed field to an internal RecipientBaseType enum, rewrites BuildPolicyJson as a switch expression with an explicit default arm that throws ArgumentException, and adds a regression-test suite.

Changes

• src/Models/Recipients.cs — new internal enum RecipientBaseType { Email, EmailDomain }; BaseType is now that enum.
• src/PostGuard.cs — RecipientBuilders.Email/EmailDomain factories pass enum values.
• src/Crypto/SealPipeline.cs — exhaustive switch with _ => throw new ArgumentException(...) default.
• src/E4A.PostGuard.csproj — InternalsVisibleTo("E4A.PostGuard.Tests") so tests can call BuildPolicyJson directly.
• tests/E4A.PostGuard.Tests/BuildPolicyJsonTests.cs — six tests covering both known base types, the EmailDomain no-@ fallback, ExtraAttribute appending, multi-recipient construction, and the new guard against an unknown enum value.

No public API change — BaseType is internal.

Test plan

• dotnet build E4A.PostGuard.slnx -c Release — green
• dotnet test --no-build --framework net10.0 — 19/19 pass (net8.0 runtime not installed locally; CI covers it)
• CI green on the PR

Reviewer quickstart

git fetch origin && git checkout fix/issue-13-recipient-basetype-enum && dotnet test E4A.PostGuard.slnx -c Release

Closes #13.

[dobby-coder]

Self-review (cannot formally approve own PR):

What I verified:

• Built and ran the full test suite locally on net10.0: 19/19 pass (6 new + existing).
• CI is green.
• BaseType becoming an internal enum is non-breaking (no public API touched).
• Switch expression with _ => throw new ArgumentException(...) is the right shape: the compiler will not enforce exhaustiveness on enums, but the runtime guard plus the new UnknownBaseType_Throws test catches a future builder being added without updating SealPipeline.BuildPolicyJson.
• Test coverage is sensible: both base types, the no-@ fallback for EmailDomain, ExtraAttribute ordering, multi-recipient, and the new guard.

Minor nits (non-blocking):

• SealPipeline.cs:84 — nameof(recipients) as the param name is technically accurate but the offending value is r.BaseType; either is fine.
• The new enum could live in its own file for tidiness, but co-locating with RecipientBuilder is reasonable given it's internal-only.

Ready for human review. Closes #13.