[callumalpass]

Why

Three pieces of code each rewrote a TaskNotes task type when its vocabulary changed: the Obsidian plugin regenerates the type from its settings and merges, the TaskNotes app patched the type itself (task-type-vocabulary.ts), and this package's patchTaskNotesMdbaseTypeSettings refused anything that changed the schema's vocabulary. A type states its statuses in up to seven places (schema enum and default, completion rule, read defaults, and the binding's values, completed_values, definitions), so three editors is three chances to leave them disagreeing.

What changes

• patchTaskNotesMdbaseTypeSettings accepts statuses, priorities and userFields (add / rename / remove) and rewrites every copy together. A test asserts the result deep-equals what buildTaskNotesMdbaseResources generates for the same settings, for canonical and migrated-v0.2 types, and that undoing the edit restores the generated type.
• Vocabulary helpers exported from @tasknotes/model/mdbase: taskNotesVocabularyProblem, taskNotesVocabularyInUse, taskNotesVocabularyValue, taskNotesUserFieldKey, the two error classes and name-based guards for them (each package entry is bundled separately, so instanceof only holds within one entry).
• taskNotesMdbaseTypeDisagreements reports copies of the vocabulary that differ, and reconcileTaskNotesMdbaseTypeVocabulary returns the type with the copies agreeing, never taking a value away.
• Only the allOf rule that requires the completion date is treated as the completion rule. A rule a collection wrote itself that tests the status is left as written and is not reported as a disagreement. (The app's own editor, shipped in tasknotes-app#399, rewrote every such rule.)
• resolveTaskNotesModelConfigFromImplementation reads a configuration from fields, binding, the type's schema and match: what an authority's catalog returns, without the type document. resolveTaskNotesModelConfigFromMdbaseType delegates to it.

Behaviour changes for existing callers

• A custom field's display name is written as the property's title and read from it before the host's remembered name. Until now the name never left the host that set it. The generated starter type has no custom fields, so its document and digest are unchanged (the starter pin test passes).
• A status or priority only the schema allows is read after the ones the binding describes, instead of being hidden. Saving the list then repairs the type.
• Camel-case spellings from early bindings are read after the current ones, so the app can drop its own second resolver for them.

Not in this change

• The generator still validates with its own, looser rules; tightening it to taskNotesVocabularyProblem could reject settings existing plugin users already have.
• The generator's type document still shares the status list between the schema and the binding with a YAML anchor. Left alone because changing it changes the published starter's text.

Testing

npm test (135 pass, 18 new) and npm run test:package.

Used by callumalpass/tasknotes-app#403 and callumalpass/tasknotes#2536, which vendor a build of this branch until it is published.

Version is bumped to 0.3.0-rc.21; nothing is published until a v0.3.0-rc.21 tag is pushed.