v1.2.0: implement deprecation policy schema fields

[chaksaray]

Summary

Implements the schema side of the deprecation policy already written
and merged in docs/specs/scaling-and-governance.md Section 3. That
document states the policy; this issue is the schema change it depends
on, explicitly deferred there rather than bundled in reactively.

Current state

status already supports active, deprecated, and draft
(schema/ave-record-1.1.0.schema.json) -- deprecated is not new. What
doesn't exist yet: merged and rejected as status values, and the
merged_into/rejection_reason fields the policy names explicitly in
Section 3. Draft records get a reduced eight-field required set per
README's thin-submission path; no equivalent conditional logic exists
yet for merged or rejected.

Separately, worth noting but not this issue's scope: GOVERNANCE.md
currently documents deprecation as requiring a deprecation_reason
field, which does not exist in the schema and which
scaling-and-governance.md Section 3 itself doesn't commit to by name
(it describes deprecated content as carrying "a note," not a specific
field). That's a documentation-accuracy gap between GOVERNANCE.md and
the schema, independent of the merged/rejected work below.

Scope

• Extend the status enum: add merged and rejected alongside the
  existing active, deprecated, and draft values.
• Add merged_into (optional string, ave_id pattern), required by a
  conditional schema rule when status is merged, pointing at the
  surviving record's ave_id.
• Add rejection_reason (optional string), required by a conditional
  schema rule when status is rejected.
• Additive changes to an enum and two new optional fields: minor version
  bump, 1.1.0 to 1.2.0, no existing record's validity changes.
• Update scripts/validate_records.py if its own status-handling logic
  (currently a draft-vs-everything-else conditional required-field set)
  needs extending to also handle merged/rejected correctly, don't
  assume the existing conditional logic already generalizes.

Out of scope

• Actually marking any existing record as deprecated, merged, or
  rejected. This issue implements the mechanism; using it on a specific
  record is a separate, deliberate decision made when a real case
  arises, not part of shipping the capability.
• Adding a deprecation_reason field for the already-working
  deprecated status, or reconciling GOVERNANCE.md's claim about it.
  Noted above for visibility, not bundled into this issue's scope.