bath: report both sides of a Hipo stake and unstake

[behrang]

Follow-up to #939, which I got wrong: it reported only the GRAM side of every Hipo operation.

A stake renders as "Deposit 2 GRAM" with nothing about the 1.710509667 hGRAM it minted — no action, no jetton value flow, and nothing in the holder's jetton history. The deposit straw swallowed proxy_tokens_minted → tokens_minted → transfer_notification into the DepositStake bubble, which carries a single currency. Tonstakers escapes this only because its mint is a TEP-74 internal_transfer that JettonMintFromMasterStraw turns into its own JettonMint, and DepositLiquidStakeStraw deliberately stops at the pool transaction. hGRAM is minted with Hipo's own op, so nothing claimed it. Unstakes lost the burned hGRAM the same way, by consuming the jetton burn they start from.

Live example: 37e56da8….

What changes

Both sides are now visible, keeping the jetton action beside the staking one rather than changing the shared action types:

	before	after
instant stake	DepositStake 2 GRAM	DepositStake 2 GRAM + JettonMint 1.710509667 hGRAM
instant unstake	WithdrawStake 46490.056 GRAM	JettonBurn 40518.686 hGRAM + WithdrawStake 46490.056 GRAM
deferred unstake	hGRAM shown, no jetton flow	same, and the flow is booked

• JettonMintHipoStraw matches tokens_minted wherever it appears, so it also covers the round-end settlement of a deferred stake. It is registered in JettonTransfersBurnsMints too, since that is the list /accounts/{id}/jettons/{jetton}/history uses and hGRAM mints are missing from it today.
• The deposit straws stop at the message the treasury proxies onwards, which is where the resolved amount lives — deposit_coins.coins is zero for "stake everything after fees".
• WithdrawHipoStakeRequestStraw starts at proxy_reserve_tokens instead of the burn, so the burn survives as its own action and the staker comes from the message rather than the burn's sender, which is the wallet itself on Hipo's unstake_all path.

Four flows that produced no staking action at all

• Round-end payout of a deferred unstake (WithdrawHipoStakeSettledStraw). A request was followed, rounds later, by an unexplained GRAM transfer. One real round-end trace yields three of these.
• A bill the treasury cannot fund, which it re-mints against the next round (WithdrawHipoStakePostponedStraw), so the unstake does not disappear in between.
• Rollback (JettonMintHipoRollbackStraw). Both rollback sites hand the hGRAM straight back, so the burn above was reading as a loss that never happened. 78 of 489 unstake traces I swept are rollbacks.
• Comment-based staking. treasury.fc routes a plain GRAM transfer carrying the comment d to the same handler — the method Hipo documents for wallets that cannot attach a payload. A 5,717,000 GRAM multisig deposit shows as a bare transfer today.

Anchoring

Every straw that moves an hGRAM balance is pinned to the treasury or the jetton master. These ops may be sent by anyone and they name the holder they credit, so an unanchored straw would let a contract have tonviewer report hGRAM arriving in, or leaving, a stranger's wallet. reserve_tokens in particular does reach the treasury from ordinary wallets on mainnet (4de4a490e0d9b523…) and is answered with a rollback. TestHipoStrawsRejectForgeries covers the three shapes a forged credit or debit would take.

Testing

go build ./..., go vet ./pkg/bath/... and go test ./pkg/bath/ (minus TestFindActions) are clean.

TestFindActions cannot run here — public liteservers no longer serve the pinned blocks, and every case fails identically with not found tx, including ones this PR does not touch. So the goldens were regenerated by rebuilding core.Trace from the raw transaction BOCs that tonapi's /v2/traces returns and replaying them through FindActions. Before trusting it, I checked that harness reproduces the four committed Hipo goldens byte for byte on an unmodified master. I also replayed the new flows against real mainnet traces. Happy to contribute the harness behind a build tag if it would be useful to you — I left it out to keep this diff to Hipo.

Second commit: fork CI

unit-tests was failing on this PR before the second commit, and it fails the same way on any pull request from a fork, including ones that touch nothing it covers. A fork cannot read secrets.LITE_SERVERS, so the variable arrives set but empty, and liteapi.FromEnvsOrMainnet reads that as a configured server list with no servers in it rather than falling back to the public ones — TestLiteStorage_TrimmedConfigBase64 then fails with server list empty. Unsetting the variable when it is empty restores the fallback, and the whole suite passes on a fork. It is one line in .github/workflows/test.yaml and entirely separable from the rest — happy to split it into its own PR if you would rather.