Schema and seed naming cleanup

# Context

Several names in the schema and seed data no longer match what they store:

- The seed JSON keys a requirement's core legal text under `rules: [...]`, an array; in practice every seeded requirement has exactly one entry, and the schema already models the same concept as `Provision` via `RequirementProvision`. Two vocabularies and an unused plurality.
- `NonComplianceDataItem` is the table that stores the verdict on each requirement evaluated against a label, but the verdict can be any of `COMPLIANT`, `NON_COMPLIANT`, `NOT_APPLICABLE`, or `INCONCLUSIVE` — only one of which is "non-compliance". The name describes one row state out of four.
- `guidance_en` / `guidance_fr` is used at multiple levels (`Legislation`, `Provision`, `Definition`, `Requirement`). On `Requirement` it holds curator instructions injected into the LLM prompt (e.g., "flag as INCONCLUSIVE if no registration number is found"). On the other entities it holds reference commentary attached to legal text. One column name, two distinct roles.

# Outcome

Schema and seed names accurately describe the data they hold, and curator-facing prompt instructions on `Requirement` are distinguishable from reference commentary on legal text.

# Acceptance criteria

- The seed representation of a requirement's core legal text uses a singular field whose name matches the schema's term for that entity.
- The table holding compliance verdicts has a name that describes the full set of verdict states, not just `NON_COMPLIANT`.
- Curator-authored prompt instructions and reference commentary on legal text are stored under distinct fields whose names reflect their role.
- Existing seed data and database rows migrate to the new names without data loss or behavioural change.