Remove DisplayName from the generic entitlement model

[blindzero]

Problem Statement

The generic entitlement model currently exposes a DisplayName field in addition to the functional identifier fields.

For a generic and provider-agnostic engine, entitlements should be identified deterministically by their stable identity, not by presentation metadata. In practice, DisplayName is ambiguous because it is provider-specific, may not be unique, may be mutable, and can suggest that entitlement matching or lookup by display value is supported or recommended.

Keeping DisplayName in the generic entitlement model increases semantic noise in the core domain model, creates documentation ambiguity, and makes examples less clear about which fields are actually required and authoritative.

Proposed Solution

Remove DisplayName from the generic entitlement model as a breaking change.

Scope:

• Remove DisplayName from the generic entitlement contract/domain model.
• Update all steps, providers, mock providers, examples, tests, and documentation so that entitlements are represented only by their functional fields.
• Ensure all entitlement examples consistently use Kind and Id only.
• Remove repository-wide references that imply DisplayName is part of the entitlement shape or that it may be used for matching.
• Review plan/debug/export examples and documentation and adjust wording/output expectations where needed.

Expected outcome:

• The generic entitlement shape is reduced to the fields that are functionally required.
• Documentation becomes explicit that entitlement identity is defined by Kind + Id.
• Users are no longer encouraged to treat display metadata as part of entitlement semantics.

Alternatives Considered

1. Keep DisplayName but document it as optional display-only metadata

This would be less disruptive, but it would keep the semantic ambiguity in the core model and continue to invite incorrect assumptions.

2. Keep DisplayName only in provider-specific outputs

This is acceptable only if it is fully outside the generic entitlement contract and clearly treated as provider-specific data rather than part of the normalized entitlement model.

3. Keep the model unchanged and only clean up examples

This does not solve the root problem. The misleading field would remain part of the core shape and would likely continue to leak into future implementations and docs.

Impact

• Does this affect existing workflows?
  • Yes. This is a breaking change for any workflow examples, provider outputs, tests, or downstream consumers that still expect DisplayName to exist on normalized entitlements.
• Any backward compatibility concerns?
  • Yes. Existing content that references DisplayName on entitlements must be updated. Because the project is still pre-1.0, this is the right time to make the model stricter and remove non-essential fields.

Additional Context

Definition of done:

• DisplayName is no longer part of the generic entitlement model.
• No shipped example, workflow, provider doc, or reference doc shows DisplayName as part of a normalized entitlement.
• Provider and mock-provider test data are updated accordingly.
• Any plan/export/debug documentation that previously showed entitlement DisplayName is updated.
• Repository-wide checks confirm there are no stale references to entitlement DisplayName in the generic model.

Test guidance:

• A dedicated test for "the field does not exist" is not required by itself.
• Tests should be added or updated only where they protect behavior, contracts, normalization, or serialization that previously included DisplayName.
• In other words: verify the contract and outputs that matter, not the absence of every removed property in isolation.