feat(transactions): let a refund set its own description and meta_data

[Shivam8584]

Implements #291 — letting a refund set its own description and meta_data instead of blind-inheriting the original's.

On the issue being closed: you reviewed this back in May and said "I'd say we go with option 1: api/transactions.go — extend refundTransactionRequest". It was then closed on 2026-08-06 in a sweep alongside #290, #225 and #345 — but unlike #345 (fixed in c8c003c) nothing had landed for this one, and refundTransactionRequest still carries only skip_queue on main. Reading that as housekeeping rather than a decision, so here's the implementation. Happy to close this if you'd rather not take it.

Stacked on #348 — please merge that first; this branch contains its three commits, so the only new commit here is c36a753. Both PRs touch refundTransactionRequest and prepareRefundTransaction, so they can't be independent. Rebases to main cleanly once #348 lands, or I can rebase this to go first if you prefer.

What changes

POST /refund-transaction/:id
{
  "description": "refund for ticket #4821",
  "meta_data": { "type": "refund", "reason": "goodwill" }
}

A refund of a transaction tagged meta_data.type = "deposit" was itself stored as a "deposit", so anything classifying ledger rows by metadata couldn't tell a refund apart from the movement it reversed.

Metadata is merged, not replaced

Worth correcting something in my own issue: I justified merging by saying a replace would drop QUEUED_PARENT_TRANSACTION. That's wrong — that key is set in QueueTransaction (transaction_queue.go:102), which runs after prepareRefundTransaction, so it isn't at risk.

Merging is still right, for different keys. setTransactionMetadata writes inflight, atomic and allow_overdraft onto the original, and those are inherited by the struct copy and read downstream (transaction_inflight.go:83, transaction_coalescing.go:604, transaction_rejection.go:71). A blind replace would drop them. Merging lets a caller reclassify the reversal while they survive.

It also gives callers a handle on a live wart: setTransactionMetadata only ever sets the inflight marker and never clears it, so a reversal of an inflight transaction inherits inflight: true even though prepareRefundTransaction explicitly sets Inflight = false — which transformTransaction then reports back (that's #293 surfacing here). Passing {"meta_data": {"inflight": false}} corrects it on that row. Not fixing #293 in this PR.

One bug worth calling out

The merge builds a new map rather than writing into the inherited one. newTransaction := *originalTxn shares the original's metadata map, so writing through it would have rewritten the transaction being refunded. There's a test for exactly this (TestPrepareRefundDoesNotMutateOriginalMetaData), and I verified against a live server that the original row still reads type: deposit after a refund overrides it to type: refund.

Threading is additive

Following how skip_queue was added to this endpoint in 8c2022a:

RefundTransaction	signature unchanged; delegates to RefundTransactionWithOptions
RefundWorkerWithOptions	signature unchanged; RefundWorkerWithRefundOptions added alongside
RefundWorker	untouched — atomic bulk rollback still uses it
prepareRefundTransaction	unexported, takes RefundOptions (2 call sites)

RefundTransaction is exported and called from 13 test sites, and isn't behind an interface, so changing its signature would be source-breaking for SDK consumers. Nothing existing changes, and an absent body or absent fields reproduces today's behaviour exactly.

Tests

10 new tests: description override, metadata merge with caller keys winning and ledger keys surviving, the aliasing guard above, overriding an inherited inflight, empty overrides being ignored rather than blanking inherited values, skip_queue behaviour preserved, and voided-original status handling unchanged.

Verified live: overriding produced {"type": "refund", "reason": "goodwill", "channel": "card", "allow_overdraft": true} — caller keys won, uninvolved keys inherited, ledger keys survived — while the original row was untouched in Postgres. A bodiless POST still returns 201 and inherits both fields.

go test ./... passes apart from internal/search, which needs Typesense and fails identically on main.