Enforce class_type taxonomy scope in the runtime validator and the schema UI link

[akijakya]

Summary

class_t dictionary attributes carry a class_type that names a node in the family's extends taxonomy (the family root such as base_module for "any module", a category: true node such as integration, or a concrete class). The valid values for the attribute are that node's concrete descendants. Two parts of the server ignore class_type and must be brought in line so scoping is enforced consistently.

Background — what already works

The sample generator (Schema.Generator.get_valid_classes/1) and the exported JSON Schema (Schema.JsonSchema.encode_class/3) already scope correctly: they list Utils.find_children(class_type) minus category: true classes. Setting an attribute's class_type to a category (e.g. integration) already restricts those two paths to that branch. No change is needed there.

The gaps to fix

1. Runtime validator does not enforce class_type. Schema.Validator (used by the /validate API) resolves a class_t entry against the whole family (Schema.find_class(family, …)) and the only membership check rejects the base class. It never consults class_type, so a class from the wrong branch — or an abstract category: true class used as a concrete value — passes validation.

   • In the class_t branch of attribute validation, verify the resolved class is within Utils.find_children(class_type) (excluding category: true), and emit a class_out_of_scope error otherwise.

2. UI type link ignores class_type. In SchemaWeb.PageView (format_type/2), a class_t attribute's type always links to /{family}s (e.g. /modules), regardless of class_type.

   • Link the family root (e.g. base_module) and unknown values to /{family}s; a category: true node to /{family}_categories/{class_type} (e.g. /module_categories/integration); and a concrete class to /{family}s/{class_type}.

3. Tests covering the validator scope error (class_out_of_scope) and the three class_t link cases.

Notes

• Keep the existing convention of naming the family root (base_skill / base_domain / base_module) to mean "any class of the family". No dictionary changes are required for this issue.
• Matching the resolved class to the valid set is done by class :name (unique within a family; present on both the find_children entries and the enriched resolved class).

Out of scope (separate follow-up)

The new integration_types attribute on the record object — adding it to record.json, the dictionary (class_type: "integration"), and the matching record.proto field, plus the end-to-end "wrong-branch" validation test — will be handled in a separate issue/PR on top of this one.