feat: add CLR attribute-based model configuration for table and key mapping with validation

[j-d-ha]

Problem

The provider currently supports DynamoDB table/key mapping through the fluent API and naming conventions, but it does not expose a provider-specific CLR attribute surface for model-based configuration. That leaves a gap for users who want to configure models directly with attributes, and it also means there is no clear validation/preference story for attribute-based configuration.

Today we already have strong model validation once Dynamo annotations are present, but there is no Dynamo-specific attribute layer for concepts like table name, partition key, sort key, or explicit attribute name.

Current state

• Fluent API exists for ToTable(...), HasPartitionKey(...), HasSortKey(...), HasAttributeName(...), and index configuration
• Naming-convention-based key discovery exists for PK/PartitionKey and SK/SortKey
• DynamoModelValidator already enforces most of the important table-key validation rules once metadata is populated
• Root-entity HasKey(...) / [Key] is explicitly rejected for DynamoDB table-key configuration
• There are currently no provider-specific CLR attributes for DynamoDB table/key mapping in src/EntityFrameworkCore.DynamoDb

Goal

Add provider-specific CLR attribute-based model configuration for the missing DynamoDB mapping concepts, and make sure it flows through the existing convention/validation pipeline with clear precedence rules.

At minimum, evaluate and likely add support for:

• class-level table mapping attribute
• property-level partition key attribute
• property-level sort key attribute
• property-level DynamoDB attribute-name mapping attribute

Design direction

Follow the same pattern used by the MongoDB provider and EF Core relational conventions:

• introduce CLR attributes with appropriate AttributeUsage
• translate them into the existing provider metadata/annotations via EF conventions
• use fromDataAnnotation: true so configuration-source precedence works correctly
• keep fluent API as the highest-precedence configuration source
• reuse DynamoModelValidator wherever possible instead of building a second validation path

Relevant provider code:

• src/EntityFrameworkCore.DynamoDb/Metadata/Conventions/DynamoConventionSetBuilder.cs
• src/EntityFrameworkCore.DynamoDb/Infrastructure/Internal/DynamoModelValidator.cs
• src/EntityFrameworkCore.DynamoDb/Metadata/Conventions/DynamoKeyDiscoveryConvention.cs
• src/EntityFrameworkCore.DynamoDb/Metadata/Conventions/DynamoKeyAnnotationConvention.cs
• src/EntityFrameworkCore.DynamoDb/Metadata/Conventions/DynamoKeyInPrimaryKeyConvention.cs
• src/EntityFrameworkCore.DynamoDb/Extensions/DynamoEntityTypeBuilderExtensions.cs
• src/EntityFrameworkCore.DynamoDb/Extensions/DynamoPropertyBuilderExtensions.cs
• docs/configuration/table-key-mapping.md

Prior art

Local precedents already in the workspace:

• MongoDB provider: CollectionAttributeConvention, BsonElementAttributeConvention
• EF Core relational: RelationalTableAttributeConvention, RelationalColumnAttributeConvention

These both use EF attribute conventions to translate CLR attributes into model configuration with data-annotation precedence.

Acceptance criteria

• Provider-specific CLR attributes exist for the supported DynamoDB mapping concepts in scope
• Attribute conventions translate those attributes into the provider’s existing metadata/annotation model
• Fluent API overrides attribute-based configuration
• Attribute-based configuration overrides pure naming conventions
• Existing Dynamo key validation rules apply equally to attribute-configured models
• Invalid or ambiguous attribute configurations produce targeted provider-specific errors
• Tests cover happy-path attribute mapping, precedence, conflicts, and invalid configurations
• Documentation is updated to describe attribute-based configuration and its precedence relative to fluent API and conventions

Notes

A narrow “validation only” story is probably not enough here, because the provider does not currently have a real Dynamo-specific attribute surface to validate. The likely implementation scope is attribute support plus validation, not validation in isolation.