feat(ts-sdk): bind award custom fields to the plugin client

[karinamzalez]

Summary

• Fixes [TS SDK] Support award custom fields in the plugin framework #1246
• Time to review: 15 minutes

Rebased onto main now that #1290 (award Zod schemas), #1294 (awards client resource), and #1295 have landed. The duplicate #1242 commits this branch previously carried are gone; the diff is reduced to the #1246 custom-fields work on top of the merged award client.

Changes proposed

• lib/ts-sdk/src/client/resources/registry.ts: add nestedSchemaName: "AwdRecipientIndividual" to the awards registry entry (and its type), since the award envelope has no top-level customFields; only the nested recipientIndividual is extensible.
• lib/ts-sdk/src/client/resources/builder.ts: add ResolvedAwardItemType and compose a plugin's compiled AwdRecipientIndividual schema into the base award envelope's recipientIndividual key, rather than swapping the top-level envelope schema the way opportunities do.
• lib/ts-sdk/src/extensions/define-plugin.ts: forward sourceSchema into buildTransforms so reverse (fromCommon) output is validated against the declared source schema instead of skipping that check.
• lib/ts-sdk/src/extensions/transforms.ts: skip output-path key validation for schemas with a non-never catchall (.loose()/.catchall(...)), since those accept keys outside their declared shape by definition; make the validateOutputPaths error direction-aware so fromCommon failures read fromCommonMapping and the customFields hint only shows for toCommon (addresses review feedback).
• lib/ts-sdk/src/client/README.md, lib/ts-sdk/src/extensions/README.md: document the nested-award-model extension pattern, plugin-bound award client calls with schema precedence, and that schemas.AwdRecipientIndividual.customFields and routes.awards.search.filters are independent extension points.
• lib/ts-sdk/examples/transforms.ts: fix the grants.gov example so it accepts the Date values the declarative field handler passes through for created_at/last_modified_at, and supply the now-validated opportunity_id source field.
• Specs: __tests__/client/award-client-types.ts (new), __tests__/extensions/define-plugin.spec.ts, __tests__/extensions/get-client.spec.ts, __tests__/extensions/transforms.spec.ts cover both transform authoring paths over AwdRecipientIndividual, plugin-bound award client typing, resource isolation, and the direction-aware output-path error.

Context for reviewers

Award custom fields live only on the nested recipientIndividual, not on Award itself. AwardBase has no top-level customFields and adding one would be a Core change, out of scope. Binding the award client therefore composes the plugin's compiled recipient-individual schema into the base envelope (registry.ts's nestedSchemaName + builder.ts's ResolvedAwardItemType) rather than following the opportunities pattern of swapping a top-level schema.

Verified by running, from lib/ts-sdk/:

• pnpm run checks (lint, format, tsc --noEmit) — pass
• pnpm run build (tsc + TypeSpec compile) — pass
• pnpm run test (684 tests) — pass
• pnpm run example:transforms — passes end to end

Additional information

None.

[SnowboardTechie]

Should #1294 land #1242 first, with this one based on its branch? This carries the #1242 commits from #1294, but an older version: shorter awards.ts JSDoc, and it's missing #1294's README fix. Landing #1294 first keeps the reviewed version and cuts this diff down to #1246. I'll hold off approving until that's settled.

[karinamzalez]

Settled by rebasing onto main now that #1294, #1290, and #1295 have merged. The duplicate #1242 commits are gone and this diff is reduced to the #1246 custom-fields work on top of the merged award client; the branch is no longer conflicting. I also updated the title and description to match the smaller scope.