2.14.0

This release restores public per-platform image provenance. Waterline 2.13.2's
image was published without it.

• The service image carries public per-platform provenance again (#241). Each
  platform image has a BuildKit SLSA v1 provenance and SPDX SBOM attestation
  manifest. The publisher also signs GitHub build provenance for the index and
  both platform digests. Published acceptance now refuses a release without
  both. Waterline 2.13.2's image (sha256:f07ad0fb…fb986) was published
  without public provenance. 2.12.3 and 2.13.0 carried it.
• A history export of a run whose details were removed by retention is no
  longer marked complete (#257). Waterline's fallback export, used when
  selected-run projections are unavailable, now follows the Core 2.17.0
  contract. It reports history_complete: false, adds
  workflow.details_state (retained or pruned) and
  workflow.details_pruned_at, and its dedupe key differs from the export
  taken before cleanup. The primary export gets the same fields from
  Workflow 2.17.0 or later. Run detail's retention notice now says the export
  is incomplete, and both export links point to it.
• When service mode starts without the PHP SDK, its message now asks for
  durable-workflow/sdk:^3.9 instead of ^2.0 || ^3.0. ^2.0 resolves to an
  SDK outside its supported boundary. Waterline still accepts installed
  ^2.0 || ^3.0 SDKs. SERVICE_MODE.md notes the same next to its tested
  ^2.0 example, which moves with the qualified product tuple.
• The schedules view refreshes itself while the top bar's Auto refresh is
  on, like the workflow list (#222). A pause, resume or new fire outcome made
  outside the page shows up without a reload. Filters, page, open dialogs and
  forms stay as they are. A refresh never overlaps a read in progress or a
  pending row action, and it waits while the browser tab is hidden. Embedded
  mode refreshes every 3 seconds. Service mode refreshes every 30 seconds,
  because each row's last outcome still needs its own Server describe call
  (durable-workflow/server#1014).
• Command dialogs show refusal reasons and messages from the engine, Server or
  a proxy as plain text (#261). Before, run detail inserted an unknown reason
  code or a backend message into the dialog as HTML, for every command. The
  query result title and the workflow list's filter validation messages are
  also shown as text now.
• A command refused with HTTP 501 backend_capability_unavailable now reads
  as "Command rejected" with "The connected workflow backend does not support
  this action." Before, run detail treated it like any other server error and
  said the outcome was unknown, although the backend had done nothing.
• Run detail offers Redrive on a failed run that the backend reports as
  eligible (durable-workflow/workflow#864). Redrive starts a successor run
  that reuses the failed run's completed steps, then opens it.
  • Embedded mode calls the workflow control plane. It needs a workflow
    package that reports can_redrive, such as 2.18.0 or later.
  • Service mode calls POST /api/workflows/{id}/runs/{run}/redrive through
    the PHP SDK, and offers the action only when the Server's describe
    response reports actions.can_redrive: true.
  • A run without that report never shows the action. A refusal shows the
    engine's or Server's reason in the run's action details.
  • Each confirmation sends one request_id, so a retry can't start a second
    successor.
  • The new redrive authorization gate follows the repair gate when it is
    null (the shipped default) or absent. Name a redrive gate to authorize
    redrive separately.
  • An embedded host whose workflow package lacks redrive gets HTTP 501
    backend_capability_unavailable instead of an error.
• Run detail labels a redrive lineage link as "Redriven from" on the successor
  run and "Redriven as" on the failed source run, rather than "Parent" and
  "Child". The labels need a workflow package that reports redrive links from
  typed history (durable-workflow/workflow#1008).
• The schedule list filters by workflow type in embedded and service mode. The
  filter combines with the status filter and stays applied while you page
  through results.
• Service mode adds a schedule visibility query filter, which the server
  evaluates. It needs a Server that accepts workflow_type and query on
  schedule list requests, such as Server 3.0.4. Embedded mode does not show the
  field. A direct embedded API request with query returns HTTP 501
  backend_capability_unavailable.
• An empty, non-string or overlong workflow_type or query returns 422 before
  Waterline reads any schedules. A rejected query leaves the entered filters in
  place so you can correct them and retry.

Service image: docker.io/durableworkflow/waterline:2.14.0, index sha256:b00ba47220af6ce4dfd73cf85852b72ea7b6913149652637628b79701d0b1c98.

• linux/amd64: sha256:d0c0d039846b6ba408f19b0b38bbe6661c5ddb79821dc11874168d10303c57fb
• linux/arm64: sha256:43e444deb984910fcc29f034a865e554b6957731bb185948b6542a0a82af6f31

Each platform image has a BuildKit attestation manifest with SLSA v1 provenance and an SPDX SBOM. It was published by protected publisher run 41782261187 from build run 41776080075. Anonymous installed, browser, recovery, request-budget and provenance acceptance passed on both architectures.

Verify the signed build provenance for the index or either platform digest:

gh attestation verify oci://index.docker.io/durableworkflow/waterline@sha256:b00ba47220af6ce4dfd73cf85852b72ea7b6913149652637628b79701d0b1c98 \
  --repo durable-workflow/waterline \
  --cert-identity https://github.com/durable-workflow/waterline/.github/workflows/service-image-publish.yml@refs/heads/main \
  --source-digest 73c63d4047e34510b784966825f13112fbe02459 --deny-self-hosted-runners

Fixes #241, #257 and #261.