Add OmitIfNull support for nested values and deprecate OmitNullStrings

[j-d-ha]

Summary

Add first-class null omission support for nested object and nested collection properties via OmitIfNull, and introduce a broader null-omission model that makes current behavior easier to understand. As part of this work, mark OmitNullStrings as deprecated/misnamed and update docs, examples, and agent skills so consumers understand the new semantics.

Problem

Today the repository behaves inconsistently around null omission:

• OmitNullStrings is named as if it only applies to strings, but in practice it already influences multiple helper-backed nullable/scalar paths.
• Nested object and nested collection mappings currently bypass that omit pipeline and hardcode AttributeValue { NULL = true } when the property is null.
• [DynamoField(OmitIfNull = true)] is documented generically, but nested object and nested collection properties do not behave consistently with that expectation.

This creates a semantic gap between naming, docs, and actual generated behavior.

Goals

• Support OmitIfNull consistently for nested object and nested collection properties.
• Introduce or complete a clear null-omission model for nullable values, including nested values.
• Deprecate OmitNullStrings and steer users toward the clearer null-omission option.
• Update all consumer-facing guidance so the behavior is unambiguous.

Proposed Direction

• Add/finish broad null omission support so nested nullable values can be omitted instead of always being written as NULL = true.
• Ensure per-member OmitIfNull works uniformly, including for nested object and nested collection properties.
• Mark OmitNullStrings as deprecated (legacy/misnamed) in the runtime API and documentation.
• Preserve compatibility intentionally where needed; if a new mapper-level option such as OmitNullValues is introduced, document precedence and migration clearly.

Scope

Code

• Update generator handling for nested nullable object and collection properties.
• Thread field-level omit metadata through nested analysis/codegen where it is currently lost.
• Add or finalize mapper-level null omission support consistent with the intended model.
• Add deprecation markers / XML docs for OmitNullStrings.

Tests

• Add/update runtime and generator tests for:
  • nested nullable object omitted when OmitIfNull = true
  • nested nullable collection omitted when OmitIfNull = true
  • interaction/precedence between mapper-level null omission defaults and field-level OmitIfNull
  • legacy OmitNullStrings compatibility behavior
• Update any snapshot tests affected by the new behavior.

Documentation

• Update API reference, core concepts, usage guides, and roadmap/docs that mention OmitNullStrings, OmitIfNull, and null omission behavior.
• Explicitly document the difference between omitted attributes and NULL = true, including compatibility implications.
• Add migration guidance away from OmitNullStrings.

Examples

• Update examples to demonstrate the preferred null omission configuration.
• Remove or annotate examples that imply OmitNullStrings is the recommended setting.

Skills

• Update skill content under .claude/skills/ (especially the dynamo-mapper skill references) so downstream agents and users get correct guidance.
• Ensure the skill explains nested null behavior, OmitIfNull, and the deprecation of OmitNullStrings.

Acceptance Criteria

• OmitIfNull works for nested nullable object properties.
• OmitIfNull works for nested nullable collection properties.
• The generated code no longer hardcodes NULL = true for nested nulls when effective omit policy says to omit.
• OmitNullStrings is marked deprecated in public API docs and code comments/attributes as appropriate.
• Documentation and examples consistently point users to the preferred null-omission approach.
• The dynamo-mapper skill docs are updated to reflect the new behavior and migration path.

Notes

This should be treated carefully because changing from NULL = true to omission changes the stored item shape. The story should make the intended compatibility policy explicit and avoid accidental silent breakage.