Add `xsd:decimal` support to the vocabulary type system

[scammo]

Summary

Add support for the xsd:decimal XML Schema datatype in the vocabulary type system, so properties like hasNumericalValue can use a semantically correct, precision-safe type.
Context: PR #579 review discussion.

Problem

The vocabulary type system currently has no support for xsd:decimal. In PR #579 (FEP-0837 Federated Marketplace vocabulary), the Measure type's hasNumericalValue property had to use xsd:string as a stopgap because xsd:float introduces IEEE 754 floating-point rounding errors (e.g., 0.1 + 0.2 !== 0.3), which are hardly acceptable in monetary and marketplace contexts.

Using xsd:string works but loses type-level semantics and requires manual parsing and validation by consumers.
More context at the following issues "Add Note about xsd:float and xsd:double Limitation"

Proposed Solution

Add xsd:decimal as a supported range type in the vocabulary type system. Once supported, properties like hasNumericalValue can be updated from xsd:string to xsd:decimal.

The key design decision is how to represent xsd:decimal values in TypeScript. This should be discussed before implementation.

Alternatives Considered

• number: Simple, but subject to floating-point precision issues. Unsuitable for financial values.
• string: Safe and dependency-free, but loses type-level semantics and requires manual parsing/validation. This is the current stopgap used in PR Add vocabulary relating to proposals, intentions and measures.  #579.
• A Decimal library (e.g., decimal.js): Provides arbitrary-precision arithmetic, but adds a runtime dependency.

Scope / Dependencies

• @fedify/vocab-tools: Code generation would need to handle xsd:decimal as a range type.
• @fedify/vocab: Vocabulary YAML files using xsd:string as a workaround (e.g., measure.yaml) could be updated once support lands.

[dahlia]

Thanks for opening this issue, @scammo! This is a well-structured write-up.

For context, there's a TC39 proposal for a native Decimal type (IEEE 754 Decimal128), but it's still at Stage 1 with no polyfill available, so we can't rely on it anytime soon.

Given that, I'm leaning toward a branded string type approach:

• At runtime, xsd:decimal values would be represented as plain strings (no extra dependencies).
• At the TypeScript level, we'd introduce a branded Decimal type (e.g., string & { __brand: "Decimal" }) so that xsd:decimal properties are distinguishable from plain string properties in the type system.
• We'd provide a factory function (e.g., Decimal("1.25")) that validates the string conforms to the xsd:decimal lexical format and returns the branded type.

This gives us:

• No runtime dependency — just strings under the hood
• Type safety — you can't accidentally pass an arbitrary string where a Decimal is expected
• Forward compatibility — when TC39 Decimal eventually lands, we can migrate the underlying representation without changing the public API shape significantly

Thoughts? If there's consensus on this direction, the implementation would touch @fedify/vocab-tools (code generation for xsd:decimal range) and @fedify/vocab-runtime (the Decimal branded type and factory function).