schemas: add tags_schema.json and wire tags into the schema test

[VasilisDragon]

Summary

#1080 has been waiting on one review ask (@rom1504: "We would need a schema for the tags file"). This adds that schema and registers tags in tools/js/test/test.js so the file is validated by CI wherever a tags.json exists. No data files change here: with no tags.json in the tree yet, the new test entry is inert (fs.existsSync guard), so this merges independently of #1080 and starts guarding it the moment it lands.

The schema is derived from the generated data rather than written ahead of it — every constraint below was checked against data/pc/1.21.8/tags.json at #1080's head (4edb806). That ordering follows the review note on #464 ("generate the data … you will need to adapt the schema once you have the data"); #1080 now provides the data half, this is the schema half.

Shape

Registry kind → namespaced tag → flattened member list. Modeled on blockMappings_schema.json (draft-07, $defs, additionalProperties: false).

• block and item are required; fluid, entity_type, and any future registry the generator emits are accepted with the same tag-map shape, so a new registry kind is not a schema-breaking change. Registry keys themselves must match ^[a-z_/]+$ — this admits path-shaped kinds the game actually has tags for (game_event, worldgen/biome, worldgen/structure) while rejecting malformed keys.
• Tag keys and members must match the ResourceLocation grammar (^[a-z0-9_.-]+:[a-z0-9_./-]+$). 0 of 414 tags / 5,421 members in the Add Minecraft pc 1.21.8 tags #1080 data violate it. The pattern is not pinned to minecraft: so datapack/mod namespaces remain representable.
• Members must be concrete entries, never #tag references — the generator flattens nested tags (0 # members in the real data), and consumers should never see one. An unflattened emission becomes a CI failure instead of a silent regression downstream.
• uniqueItems on member lists (0 duplicates in the real data; catches double-emits).
• Empty member lists are deliberately valid: vanilla ships empty tags — on 1.21.8 both minecraft:incorrect_for_diamond_tool and minecraft:incorrect_for_netherite_tool are empty. A min-1 constraint (as drafted in Tag schemas #464) would reject the real file.

Verification

• The unmodified Add Minecraft pc 1.21.8 tags #1080 tags.json validates with the repo's Ajv setup (new Ajv({ verbose: true }), same as test.js).
• 22-case battery against the same setup — real file, future registries (game_event, worldgen/biome), modded namespaces, and empty-array cases pass; root-as-array, missing registry, non-array tag value, non-string member, malformed tag key, #tag member, duplicate members, malformed/miscased registry keys, null/array registry values, and empty-string members are all rejected.
• Cross-referential integrity: all 5,417 block/item/entity_type members in the Add Minecraft pc 1.21.8 tags #1080 file exist in the same head's blocks.json / items.json / entities.json — 0 dangling references. (fluid's 4 members have no data file to check against.)
• Full tools/js suite: 1762 passing / 1 pending before and after this change — no behavior change while no tags.json exists.
• Merged-state simulation: with Add Minecraft pc 1.21.8 tags #1080's tags.json + dataPaths entry applied locally, the suite goes to 1763 passing / 1 pending — the +1 is pc 1.21.8: tags.json is valid — and audit dataPaths stays green both directions. Corrupting one member to #minecraft:planks flips exactly that one test red (should match pattern "^[a-z0-9_.-]+:[a-z0-9_./-]+$").
• json-schema-to-typescript (which node-minecraft-data generates its typings from, walking schemas/) compiles this schema to a usable Tags interface.

On the second question in #1080 ("are we adding it only for 1.21.8?"): the schema is version-agnostic — coverage can grow as PrismarineJS/minecraft-data-generator#56 stabilizes on older versions (extremeheat noted pre-1.20.5 versions lack Mojang mappings there). Versions without a tags.json are not validated against it.

I left README's "Data provided" row and the doc/add-data-new-version.md entry for when the data itself lands (#1080 / the generator work) rather than advertise tags the repo doesn't provide yet.

Context: #463 (2021) proposed a tags schema and #464 closed waiting on generated data to derive one from. With #1080 staged, this is the remaining half of that sequence, and the data-side prerequisite for exposing mcData.tags in node-minecraft-data (#412 discussion).