Adopt physical_path replicate field (baton 6.1.0 schema addition)

[jmtcsngr]

Context

Upstream baton 6.1.0 (2026-07-02) added a physical_path field to
every replicate JSON object:
wtsi-npg/baton#339 ("Add physical path
reporting for replicates").

Diff summary (src/list.c, src/json.c, src/json_query.c upstream):

• New catalog column selected: COL_D_DATA_PATH.
• New JSON key: JSON_PHYSICAL_PATH_KEY = "physical_path".
• make_replicate() grew a phys_path parameter, packed as a plain
  string alongside resource / location / checksum / replicate
  / status.

baton-rs is still pinned to 6.0.0 and its Replicate type
(src/types.rs:103-109) has no equivalent field:

pub struct Replicate {
    pub checksum: String,
    pub location: String,
    pub resource: String,
    pub number: u32,
    pub valid: bool,
}

fetch_replicates (src/operations/list.rs:453-503) selects
SHIM_COL_DATA_REPL_NUM / SHIM_COL_D_DATA_CHECKSUM / SHIM_COL_R_LOC
/ SHIM_COL_D_RESC_NAME / SHIM_COL_D_REPL_STATUS — no path column —
and builds Replicate { checksum, location, resource, number, valid }
positionally off those five columns.

What needs to change

1. Shim: add a SHIM_COL_DATA_PATH (or similarly named) entry to
   the shim_col_t enum in shim/ffi_shim.h, map it to COL_D_DATA_PATH
   in translate_col() (shim/ffi_shim.c), mirror in src/ffi.rs. Same
   declare/implement/mirror pattern adopted in Session 4.5 for every
   prior shim addition.
2. Replicate (src/types.rs): add pub physical_path: String
   (or Option<String> if we want to tolerate older servers /
   STRICT_BATON_COMPAT-off honesty — needs a decision, see below).
3. fetch_replicates (src/operations/list.rs:464-500): add the
   new q.add_select, extend the positional row-unpacking, populate
   the new field on Replicate.
4. Tests: extend the existing --replicate integration coverage
   in tests/list.rs to assert the new field is present and non-empty
   for a staged data object.
5. Docs: update the Cross-cutting conventions / relevant module
   doc if this is the first field baton-rs adds because a newer
   upstream release added it (i.e. explicitly a post-6.0.0 schema
   diff, not a fresh gap analysis against 6.0.0).

Open question — gate behind version pin or always emit?

baton-rs's Target baton version for parity is currently pinned at
6.0.0 (see SESSIONS.md Project constants; BATON_COMPAT_VERSION
in src/version.rs). physical_path is a 6.1.0 addition. Two options:

• (a) Bump the parity pin to 6.1.0 (or at least 6.0.1) and treat
  physical_path as part of that re-pin's scope — cleanest, matches
  "schema changes in later 6.x releases are explicit decisions rather
  than silent drift" (PLAN.md's own stated policy for this exact
  situation).
• (b) Add the field now, ahead of a formal re-pin, since it's
  purely additive (new key, no existing key changes shape) and
  downstream consumers that already expect it (if any) benefit
  immediately.

Tracked here rather than decided implicitly; see the companion
version-pin decision in progress on the baton-rs side (SESSIONS.md
catch-up work).

Related

• Upstream baton 6.1.0: https://github.com/wtsi-npg/baton/releases/tag/6.1.0
• Upstream PR: Add physical path reporting for replicates wtsi-npg/baton#339
• Session 4.5 shim convention (declare in .h, implement in .c,
  mirror in src/ffi.rs): SESSIONS.md Session 4.5 log.

[jmtcsngr]

Implemented and merged to main via PR #102 (chore/bump-baton-compat-6.1.0): SHIM_COL_DATA_PATH → COL_D_DATA_PATH in the shim, Replicate.physical_path: String in src/types.rs, wired into fetch_replicates. Verified against partisan's own test_replicas assertion (partisan PR #349) after bumping the partisan pin to devel HEAD -- CI green on both 4.3.4 and 4.3.5.