0.27.0

Added

• An enum variant carries its own wire spelling. TypeBody::Enum carried Vec<String>, so
  Naming was reachable from a domain, a command, an event, an error, a view and a field, and not
  from a variant. A variant whose wire form is not derivable from its name could not be declared at
  all. A variant is now authored either as a bare name or as a mapping that also carries wire,
  display, summary and code:

  variants:
    - name: Stop
      wire: ""
    - Flag

  The case that asked for it is one command over several route shapes, where one variant's path
  suffix is empty and the others are not; without a declared spelling the alternatives were
  splitting the command to satisfy a path, or writing the table again in every target. An authored
  empty string is a wire spelling rather than an absent one, because that variant is the route with
  no suffix. docs/design/enum-variant-wire-names.md states the shape.

• Specification format ess/5. A variant that declares naming under ess/1 … ess/4 is
  refused with unsupported_format_version at types.<type>.variants.<variant>. A bare variant
  list is admitted by every format, and a variant that declares nothing serializes back as a bare
  name, so every specification and IR document written before this keeps its bytes.

• Delta format ess-diff/5, and three cases on TypeChange — VariantWireNameChanged,
  VariantDisplayNameChanged and VariantSummaryChanged. A variant's own name does not move when
  its wire spelling does, so the variant set and the variant order both said nothing and the
  comparison returned an empty delta for a change a deployed consumer breaks on. A delta carrying
  one of the three is refused by a reader of ess-diff/1 … ess-diff/4.

Changed

• A generated JSON Schema enumerates an enum's wire spellings rather than its variant names. For a
  variant that declares no naming the two are the same string, so no existing model moves. The CLI
  contract keeps the authored names, which are what an operator types.

• The workspace's internal dependency requirements move from 0.26.0 to 0.27.0. A minor bump
  invalidates a caret requirement, so all 20 workspace.dependencies entries move with the
  workspace version. fuzz/Cargo.lock is its own workspace and moves with them.

Known

• A variant name is still not checked against a spelling pattern on the way in, as it never has
  been. The published schema therefore declares none for either authored form, so an author's
  editor cannot refuse a document this repository assembles.

• task consumer-check is red, for two reasons, and ci.yml:89 runs the gate with
  SKIP_CONSUMER_CHECKS=true, so it gates neither CI nor this release. The lane reports both in one
  refusal:

  extraction/classification refused: unclassified concrete consumer entry
  ess_cli::bin(ess)::enum::SuiteTarget/variant/Typescript; finite review required;
  accounting diagnostics: {"SchemaDocumentMetadata":0,"details":"unknown claimed model
  wire:RawSpecFile#/definitions/NamedType/oneOf/2/properties/variants/items/type",
  "format":"ess-consumer-accounting/1","no_cells_admitted":true,
  "status":"PROVISIONAL_ACCOUNTING_REFUSAL"}
  

  The unclassified SuiteTarget/variant/Typescript arrived with the origin/main merge 7bf315a9
  (PR 47) and is untouched here — SuiteTarget at crates/edge/ess-cli/src/main.rs:601 held only
  Ir and Go at 0.26.0. The unknown claimed model is this release's: variants became an anyOf
  of a bare name and a mapping, so .../variants/items/type no longer exists and
  crates/edge/ess-xtask/src/consumer_coverage/reviewed-candidates.json still claims it. That file
  is a reviewed artifact — cargo xtask consumer-extract writes a fresh UNACCEPTED checkpoint
  elsewhere and never rewrites it (consumer_coverage/mod.rs:47-133), and preservation.rs:15
  only reads it — so retiring the claim is a finite review, not a regeneration, and is not done
  here.