[Py SDK] Support award custom fields in the plugin framework #1247

Summary

Let plugin authors extend the individual recipient of an award with custom fields. Core v0.5 places customFields on AwdRecipientIndividual, not on the award envelope. A plugin should be able to register a typed recipient custom-field model, source schema, mappings or transforms, and plugin.get_client() should compose the plugin's recipient model into AwardBase when parsing award responses by default. This uses the existing plugin contract. Version-aware plugins are separate v0.10 work.

Custom award filters are not part of this ticket. They live in the awards client ticket (#1243), because standard and custom filters run through the same search classifier. This follows #1241 (award models) and #1243 (awards client). This is the Python counterpart to #1246, following the nested-recipient implementation in #1299. Adding top-level award custom fields is out of scope.

Acceptance criteria

• A plugin can supply PluginSchemas(AwdRecipientIndividual=...), and leaving it out falls back to the base recipient model within AwardBase
• Typed AwdRecipientIndividual[RecipientFields] models expose typed custom fields while keeping the untyped default
• Recipient schema entries support source schemas, mappings, and to_common/from_common transforms with the existing error behavior
• plugin.get_client() composes the plugin's recipient model into the award envelope by default for client.awards.get, .list and .search, separately from opportunities, while keeping per-call overrides and typed access to recipient_individual.custom_fields
• Tests cover typed field access, both transform directions, invalid output, fallback, override precedence, and no opportunity regressions
• Award filters from [Py SDK] Add an awards client resource #1243, standard and custom, keep working unchanged
• Extension and client docs include an award recipient custom-field example and explain the difference between schema custom fields and route custom filters