feat: support numeric priority values

[Moyf]

Try to close #1289

I had the AI write it, and after finishing, I roughly reviewed the changes it made.
Then I realized the amount of changes involved is indeed quite substantial, and I understand the difficulty of this requirement now. 😅

However, most of the changes are type conversions—which, in a way, is quite suitable for AI to handle ;)

This PR is just a reminder and is not urgent to merge. I’ll test it locally for a while to see if it works properly.

Also, if anyone else is interested in the priority of numeric types, feel free to give it a try. Salute!

---

• Add support for both string and number types in priority values
• Add 'Priority value type' setting to choose output format (text/number)
• FieldMapper converts priority to chosen format when writing frontmatter
• Default to text values for backward compatibility

[callumalpass]

Thanks for putting this prototype together. I reviewed the shape of the patch and I do not think we should merge it as-is.

The core priority field is currently treated as an enum-like string throughout TaskNotes: stored value, label, color, weight, parsing, menus, task creation, filtering/grouping, CSS classes, API shape, and field mapping all assume that core value is a stable string. Supporting both string and number values would require a much broader compatibility and migration design than this PR can safely add as a one-off setting.

For the formula use case, the lower-complexity path is to use a custom number field for numeric importance/scoring while leaving priority as the visible labeled category, or to use sortable string values like 1-urgent, 2-high, etc. I would close this PR and the related numeric-priority requests for now unless we later decide to redesign core fields around typed schemas more broadly.

[Moyf]

Thanks for putting this prototype together. I reviewed the shape of the patch and I do not think we should merge it as-is.

The core priority field is currently treated as an enum-like string throughout TaskNotes: stored value, label, color, weight, parsing, menus, task creation, filtering/grouping, CSS classes, API shape, and field mapping all assume that core value is a stable string. Supporting both string and number values would require a much broader compatibility and migration design than this PR can safely add as a one-off setting.

For the formula use case, the lower-complexity path is to use a custom number field for numeric importance/scoring while leaving priority as the visible labeled category, or to use sortable string values like 1-urgent, 2-high, etc. I would close this PR and the related numeric-priority requests for now unless we later decide to redesign core fields around typed schemas more broadly.

Yes, thanks for the review! I've also realized the various issues that could come from forcing this property to be compatible with two types. Perhaps the best approach is to change priority from a number type to a text format like "1-High", and then use a formula in Bases to convert it.