chore: rebase andamio stack onto upstream v1.2.0 (v1.2.0-andamio.2)

[adrian1-dot]

Summary

Rebases the Andamio dolos patch stack from a v1.0.3 base onto upstream txpipe/dolos v1.2.0, shipping as tag v1.2.0-andamio.2. Decision + rationale: Andamio-Platform/andamio-dev-kit-internal#127 (rebase-now over defer-to-v11).

Supersedes #1 — its tx_hash fix ships here as Patch 4 (byte-clean port onto v1.2.0).

What's in the stack now

Patch	Status on v1.2.0
1 — base_path (minibf)	kept (clean cherry-pick)
2 — fill_input_as_output (grpc watch)	DROPPED — upstream-native since v1.1.0 (txpipe/dolos#962)
3 — validate.rs (testing-only)	kept (clean)
4 — tx_hash from TxoRef (minibf)	kept (clean, byte-clean port)

Reviewing this PR

⚠️ The diff against main is dominated by the upstream v1.0.3 → v1.2.0 delta (the ~45 upstream commits below) — not meaningful to review line-by-line. The actual Andamio re-application is a single commit (3835eb2), 8 files on top of v1.2.0:

git diff v1.2.0..andamio/v1.2.0-rebase

→ crates/core/{config,lib}.rs, crates/minibf/src/{lib,mapping}.rs + README.md, crates/cardano/src/validate.rs, src/bin/dolos/minibf.rs, docs/content/apis/minibf.mdx. src/serve/grpc/watch.rs is intentionally untouched (Patch 2 dropped).

Landing: per RELEASING.md, main advances by force-push to this branch after review — not the Merge button (a merge would splice the old v1.0.3 stack and the new one together). See the process question in the comment below.

Patch 2 drop — evidence

Dropping fill_input_as_output was gated on confirming upstream populates as_output natively. Verified on stock v1.2.0 (no fork patches):

• WatchTx populates as_output on 100% of inputs — 570 txs / ~2,000 inputs (spent 1165/1165, reference 835/835).
• andamioscan parity: fork (v1.0.3-andamio.1, with Patch 2) vs rebased v1.2.0 (without), andamioscan's exact predicates over the recent shared window — 24/24 Andamio txs byte-identical on inputs + reference_inputs as_output; identical tx-set.
• andamioscan safely ignores the restored upstream idle action (GetApply() nil-guard).

Validation

• Functional: addresses/{addr}/utxos returns non-empty tx_hash, byte-matches the prod fork node.
• Sponsored-gateway e2e (gateway + sidecar from source, against this build): a complete on-chain enterprise-sponsored build + reconciler → CONFIRMED passed. The later step failed on a known utxos.dev-side submission bug, not dolos.

⚠️ Deploy requires a resync

Deploying v1.2.0-andamio.2 over a running v1.0.3-andamio.1 node forces a Mithril re-bootstrap, for two reasons:

1. WAL schema force-reset — upstream v1.1.0 (txpipe/dolos#984) versions the on-disk WAL and force-resets on incompatibility (WAL version is incompatible).
2. Full-archive switch — the planned max_history removal (full-archive mode) needs the entire chain history re-imported; the node currently keeps only ~36 h.

Operational estimate (@nelsonksh): preprod ~1.5 h, mainnet 12–20 h. Local devkit is exempt (data already migrated to v1.2.0 format).

📝 RELEASING.md may need adjustment to document this deploy-time resync — it currently covers cutting the release but not the upgrade consequence on a running node.

Links

• Andamio-Platform/andamio-dev-kit-internal#127 — rebase decision + handoff
• Andamio-Platform/andamio-dev-kit-internal#126 — tx_hash coordination
• Andamio-Platform/andamio-dev-kit-internal#95 — original Mesh empty-tx_hash symptom (closed)
• fix(minibf): source address-utxo tx_hash from TxoRef, not archive block_data #1 — superseded by this PR

cc @nelsonksh

[adrian1-dot]

@nelsonksh — flagging how to land this, since a rebase-onto-new-upstream doesn't fit the normal PR flow and I'd like your call on the process:

• The 46-commit list is just the upstream v1.0.3 → v1.2.0 history; the only Andamio change to review is 3835eb2 — git diff v1.2.0..andamio/v1.2.0-rebase (8 files).
• Per RELEASING.md, rebases land by force-pushing main to this branch — not the Merge button (a merge would splice the old v1.0.3 patch stack and the new one together).

How would you like to approach it?

1. Review 3835eb2 here → approve → force-push main to andamio/v1.2.0-rebase (PR auto-closes). And: who force-pushes — you or me?
2. A different review/landing flow you'd prefer — open to your call.

Either way the deployable artifact (tag v1.2.0-andamio.2 + GHCR image) is already built and validated; this is just about advancing main and your sign-off before the redeploy (which needs the WAL/full-archive resync noted in the description).

[nelsonksh]

Option 1, please drive the force-push — you authored the rebase and RELEASING.md is your playbook. Just approved 3835eb2; you advance main at your convenience.

Independent of ops/redeploy — image is already on GHCR, so the fork-main advance has no deploy effect. Ops PR Andamio-Platform/andamio-ops#159 (drops max_history, adds max_rollback) lands separately when @workshop-maybe / @xeeban review, which is what actually triggers the staging WAL Mithril resync.