`metadata_version` is declared but cannot be enforced as it is written

[dieterbaier]

Problem

metamodel/artifact.schema.yaml:134 declares the field as:

metadata_version:
  type: string
  default: "1.0"

It is not listed under required, it carries no enum, and
scripts/validate-metamodel.rb does not mention it. Every consuming repository
therefore carries a field on every artifact that records an intention nothing
verifies.

This is not the same gap as #48. That issue would make validation fully
schema-driven and names enum values among the rules it would cover, which
closes the mechanism half. It does not close this one: a JSON Schema default
is an annotation and not a validation rule, so full schema validation of the
current schema would still accept any string, and would still accept the field
being absent. The remaining gap is in the schema, not in the validator.

Why the field matters

Its only purpose is to let a consumer notice that content and the tooling
validating it were written against different versions of the metamodel contract.
Toolkit assets reach consuming projects by copy or by checkout (#22, #26), so a
checkout that is simply older than the content beside it is the expected failure
rather than an exotic one. As written, the field cannot detect it.

Possible resolutions

The issue should pick one; both are defensible and the current state is neither.

1. Declare the accepted versions. Give the field an enum and decide whether
   it is required. With Replace partial artifact metadata validation with full JSON Schema validation. #48 in place, no additional validator logic is needed —
   the schema enforces it. The default then goes, because a default on a
   required field says nothing, and on an optional one it says the absent case is
   silently accepted.
2. Say it is informational. Keep the field, document that nothing enforces it
   and that it carries no guarantee, and let consumers who want enforcement add
   their own. This is a smaller change and an honest one.

Evidence from a consuming project

profile-dieterbaier enforced the equivalent field in its own profile metamodel
(dieterbaier/profile#83). What that surfaced, offered as input rather than as a
proposal:

• The accepted set was put in the schema as the enum on the field, so the
  validator and the contract cannot hold different answers, and a build can read
  the accepted versions without running the validator.
• The validator resolves the schema from its own directory rather than from the
  root it was pointed at. This is the part that makes the check work at all: when
  a project validates its content through a borrowed checkout, the answer has to
  come from the checkout doing the validating.
• An absent value was made an error rather than the initial version. A default
  lets content say nothing about its contract and still pass, which is the case
  the field exists to remove.

This concerns profile content and its private-to-public lifecycle. Nothing in it
argues that architecture documentation needs the same lifecycle, and this issue
does not propose one.

Acceptance criteria

• metamodel/artifact.schema.yaml either declares which metadata_version
  values are accepted, or states that the field is informational and that
  nothing enforces it.
• If accepted values are declared, the absent case is decided explicitly —
  required, or defined as a specific version — and the schema says which.
• A consuming project can determine the accepted set from the toolkit assets
  without running the validator.
• Where the version is raised, and what raising it involves, is documented
  for consumers whose content declares the old value.

Related

• Replace partial artifact metadata validation with full JSON Schema validation. #48 — full JSON Schema validation. Closes the mechanism half of this.
• Slice #22.4: Define toolkit asset update mechanism for consuming projects #26, Fix included artifact heading levels and refresh dogfood example #22 — toolkit asset drift in consuming projects, which is the situation
  the field is supposed to make visible.