Harden Rule 29 duplicate-schema fingerprinting to avoid false positives

[Copilot]

Rule 29 was over-collapsing structurally similar schemas by fingerprinting only coarse property/type shape. That caused false duplicate matches when schemas differed in $ref targets, required fields, constraints, or descriptions.

• Fingerprint normalization

  • Extract Rule 29 fingerprinting into a dedicated helper: build/lib/duplicate-schema-fingerprint.js
  • Fingerprints now include:
    • full $ref paths
    • sorted required arrays
    • property and schema description
    • validation constraints such as minLength, maxLength, pattern, minimum, maximum, and related bounds
    • nested schema structure in items, additionalProperties, and allOf / anyOf / oneOf

• Validator wiring

  • Replace the previous inline Rule 29 fingerprint function in build/validate-schemas.js
  • Preserve deterministic matching for semantically equivalent schemas by sorting property keys and required entries

• Focused regression coverage

  • Add tests/validate-schemas-duplicate-schema-fingerprint.test.js
  • Cover cases where fingerprints must now diverge:
    • different full $ref paths
    • different required sets
    • different constraints
    • different descriptions
  • Also cover the non-regression case where equivalent schemas with reordered fields still fingerprint identically

const schemaA = {
  type: "object",
  required: ["name", "id"],
  properties: {
    id: { $ref: "../../v1alpha1/core/api.yml#/components/schemas/uuid" },
    name: { type: "string", minLength: 1, description: "Display name." },
    created_at: { type: "string", format: "date-time" },
  },
};

const schemaB = {
  ...schemaA,
  properties: {
    ...schemaA.properties,
    id: { $ref: "../../v1beta1/core/api.yml#/components/schemas/uuid" },
  },
};

// Previously could collide; now fingerprints differ because the full $ref path differs.