refactor: eliminate multiple value choices in schemaKey Literals

[candleindark]

Eliminates the multiple value choices in the schemaKey Literals of Contributor and Activity, the last two classes that offered more than one.

The extra choices were unreachable at runtime, since ensure_schemakey pins every instance to its own class name, and in the generated JSON Schema they produced a const and a contradicting enum on the same property. They existed to keep mypy quiet, so removing them costs # type: ignore[assignment] on five subclass overrides, as Asset.schemaKey already does.

That exposed wasGeneratedBy, which the second commit adjusts:

• CommonModel.wasGeneratedBy becomes list[Union[Activity, Project, PublishActivity, Session]]. Its former Sequence[Activity] reads as "any Activity subclass", but for JSON input it accepted only Activity itself.
• BareAsset stops narrowing that set and keeps the field only for a reworded title and description.
• Sequence gives way to list.

Why the multiple value choices are a problem

The schemaKey post-processing in __get_pydantic_json_schema__ collapses enum into const only for a single-member enum, so both classes emitted the two keys at once. For Activity:

"schemaKey": {"const": "Activity", "default": "Activity",
              "enum": ["Activity", "Project", "Session", "PublishActivity"]}

A validator has to satisfy both, so the effective constraint was already just "Activity" while the enum advertised three values the schema would never accept. Anything reading the schema to enumerate valid keys, a UI or a code generator, saw the wrong set.

Why BareAsset.wasGeneratedBy goes away

List[Union[Session, Project, Activity]] admitted Activity yet turned away PublishActivity, which is inconsistent, since every PublishActivity is an Activity.

That set is also inexpressible in LinkML once schemaKey serves as the type designator: a class-valued range expands over the class's descendants, whether the class stands as the range itself or as an alternative within an any_of. See designates_type: true makes generated artifacts resolve a superclass-typed slot value to its concrete subtype in the migration playbook.

The consequence for this field is recorded there too: the BareAsset.wasGeneratedBy range override in models_merge.yaml is a deliberate no-op. gen-pydantic already renders CommonModel.wasGeneratedBy as exactly the union proposed here, and the override renders as a nested union that flattens to the same four members. That finding says the override should be revisited once the Pydantic definition is corrected, which is what this PR does.

Separately, the old title, "Name of the session, project or activity.", described a name field rather than a list of activities, and both strings named a class set that no longer holds. They now follow Dandiset.wasGeneratedBy: title="Associated activities", description="Activities that generated this asset."

Why Sequence gives way to list

Sequence was never a modeling decision. 23e56855, part of #100, the PR that first added mypy here, switched both fields from List to Sequence purely to sidestep list's invariance for Dandiset's narrowing override, and the name appears nowhere else in models.py.

Pydantic's Sequences documentation says "In most cases, you will want to use the built-in types (such as list or tuple) as type coercion will apply", reserving Sequence for "when you want to preserve the input type during serialization", which these models do not need given they round-trip through JSON. Concretely, dandi-cli calls .append on BareAsset.wasGeneratedBy, which Sequence does not provide.

Both defects entered together, incidentally: f224281a introduced all three multi-value Literals and 23e56855 introduced Sequence three minutes later, both in #100, neither with a validation rationale.

Behavior change and downstream check

Asset and BareAsset metadata now accept a PublishActivity in wasGeneratedBy, which the JSON Schema previously rejected. This is a widening only, so nothing previously valid becomes invalid.

• dandi-cli's dandi/metadata/core.py calls .append on BareAsset.wasGeneratedBy, which type-checks again now that the field is a list.
• dandi-archive has no Python reference to wasGeneratedBy; it handles metadata as dicts through dandischema.metadata.validate / migrate. Its frontend wasGeneratedBy (web/src/types/schema.ts, typed Project[]) is the Dandiset field, whose accepted class set is unchanged here: Dandiset.wasGeneratedBy only moves from Sequence[Project] to list[Project].

[codecov]

Codecov Report

❌ Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.96%. Comparing base (510f161) to head (e45422b).

Files with missing lines	Patch %	Lines
dandischema/models.py	0.00%	10 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #437   +/-   ##
=======================================
  Coverage   47.96%   47.96%           
=======================================
  Files          19       19           
  Lines        2427     2427           
=======================================
  Hits         1164     1164           
  Misses       1263     1263           

Flag	Coverage Δ
unittests	47.96% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[yarikoptic]

I added release just to see how schemata changes or not... to be removed before merge