Tidy metadata plugin attributes

Hi @pdureau and @just_like_good_vibes!

I used Claude to double-check for edge cases, and it identified two potential concerns.

I added a NULL guard to getChoices() and SourcePluginBase.

There are also concerns about the metadata annotation using the wrong entity type. We currently use DerivableContextMetadata, while Claude suggested that source plugins should use SourceMetadata instead.

Claude also suggested several more invasive code changes, but I didn’t implement them without discussing them first.

Concerns identified by Claude:
1. getChoices() — unguarded NULL->provider (DerivableContextSourceBase.php:503-507)

  $metadata = $derivable_context['metadata'];   // was: ?? []
  'provider' => $metadata->provider,            // was: $metadata['provider'] ?? NULL

The DerivableContext attribute now defaults metadata to NULL. Any derivable-context plugin that doesn't route through EntityFieldSourceDeriverBase (i.e. any contrib one) has metadata === NULL → fatal.
Core's two plugins both inherit a SourceMetadata, which is the only reason it's green.

2. getCustomPluginMetadata() — unguarded property access (SourcePluginBase.php:397-403)
return $plugin_definition['metadata']->{$key}; // was: guarded, returned NULL on miss
Fatals if metadata is NULL (any non-field Source plugin) or a key is absent. Safe today only because the two callers are field sources that always have metadata — but this is a general protected helper any source subclass can call.

Thanks Pierre, your work surfaced many improvements to do. Thanks smovs too :)

I pushed another proposal on a separate branch, where metadata stays a plain array: 3591167-bc-harness-array-metadata (MR !537).

As we discussed, this work has several objectives:
1. Derivation backward compatibility: derived plugins must keep working across future refactors, same IDs, working plugins, correct data, proven by tests.
2. simplify and trim metadata: keep only what is strictly necessary in derived plugin definitions, less code, no per-plugin-type diversity.
3. Metadata key discipline: array preferred over object, and the remaining keys named once, not hardcoded everywhere.
4. Smaller API surface if possible

What I pushed:
- Tests first: a recorded fixture of the derived plugin IDs (entity references had no coverage at all), assertions on contexts, tags and metadata values, and a check that a stored source_id still resolves.
- Removed the metadata keys: entity_type_id, entity_bundle, field_formatter, the classification flags.
- SourceMetadataKey string enum as the single source of the key names, with a protected getMetadata() accessor. About #7: field_name and property are not special, just the only keys read at runtime.
- getCustomPluginMetadata() removed

Impact on code: -34 useful lines of codes, 2 public methods removed, more tests, 1 file added (SourceMetadataKey)

Needs review.

Hello @pdureau,
sorry i realize my previous comment was probably too short about what !537 actually changes, so let me describe it better.

The metadata stays a plain array, same place, same nesting. Only its content shrinks:

Before:

'metadata' => [
  'field' => ['type', 'configurable', 'editorial', 'parent_base', 'base', 'cardinality'],
  'field_name' => ..., 'property' => ..., 'entity_type_id' => ..., 'entity_bundle' => ..., 'provider' => ...,
] + 'field_formatter' => TRUE merged by FieldFormatterSourceDeriver.

After:

'metadata' => [
  'field' => ['type', 'cardinality'],
  'field_name' => ..., 'property' => ..., 'provider' => ...,
]

Every removed key has zero readers, in ui_patterns (and none found in drupal ecosystem).
The enum does not replace the array: SourceMetadataKey only names the keys, once, and getMetadata() reads them.

About your table:
- The classification flags are configurable, editorial, parent_base and base: the same four FieldMetadata flags as in !504 , computed by getEntityFieldsClassification() (removed in the MR) and read by nobody. So the removals of !537 are a superset of the removals of !504 .
- Field metadata: kept, trimmed to type and cardinality, the only keys read at runtime.
- The DerivableContextMetadata class only wrapped a value parsed from the plugin ID at runtime, and !537 renames that method parsePluginId() to say what it really does.

So I believe the merge you describe is what !537 already contains: the DTO classes are the only part of !504 left out, and they are the risky part for 2.0.x.