fix(safe): preserve pending transaction gas fields

[dtopenclaw]

Fixes #2278.

Summary

• preserve safeTxGas, baseGas, gasPrice, gasToken, and
  refundReceiver when projecting pending Safe transactions
• update the action catalog to describe the complete current output shape
• align the Safe plugin documentation with the additive fields
• cover the execution-critical gas/refund projection with a focused mocked
  Transaction Service test

The upstream response already contains these values; this change adds no
request and does not alter existing fields or filtering behavior.

Verification

• corepack pnpm@9 exec vitest run tests/unit/safe-pending-transactions-projection.test.ts tests/unit/protocol-safe.test.ts tests/unit/validate-workflow-structural.test.ts tests/unit/credential-map-coverage.test.ts — 66 tests passed
• corepack pnpm@9 run discover-plugins
• corepack pnpm@9 run type-check
• corepack pnpm@9 exec biome check plugins/safe/steps/get-pending-transactions.ts plugins/safe/index.ts docs/plugins/safe.md tests/unit/safe-pending-transactions-projection.test.ts
• git diff --check

AI assistance was used to prepare this contribution. I reviewed the resulting
changes and ran the checks above in a clean, lockfile-pinned checkout.

[github-actions]

About the build check on this pull request

This pull request comes from a fork, so GitHub does not pass it the credentials build normally uses for our image registry cache and staging build configuration. The build still runs and still compiles the image, so a red build here is real; it just takes longer than on team branches.

Every workflow run on a pull request from a fork also waits for a maintainer to approve it, so checks can sit at "awaiting approval" for a while after each push. Nothing is needed from you for either of these.

[joelorzet]

Scope is exact. Issue #2278 names five fields and this adds those five, nothing more.

I checked the part that could have gone wrong. SafeMultisigTransaction already declared all five with the same types the projection uses, so the values were fetched and thrown away. No new request, no change to existing fields, no change to filtering. The catalog string and docs/plugins/safe.md now match the code's field order, and you fixed two stale omissions in that string while you were in it.

One change, left inline.

Smaller point on the test: it is a single happy path with toMatchObject over a fully populated fixture. Given what these fields are for, pinning the benign case as well, a zero gasPrice with the zero address for gasToken and refundReceiver, would record what a safe transaction looks like next to what a hostile one looks like.

[joelorzet]

The fields are here, but nothing tells a reader why they matter.

Issue #2278 is not a completeness report. Its case is that execTransaction pays a refund from the Safe to refundReceiver and calls gasToken, so a hostile pair drains whoever executes, and that zeroed values look exactly like a benign transaction. A consumer that cannot see those two fields cannot refuse them.

After this change they can see them, and the docs give them no reason to look. The five names sit in a comma-separated run beside nonce and submissionDate, and the "When to use" line two lines down still names only DELEGATECALL, proxy upgrades and unknown targets.

Please add a sentence. Something like: a non-zero gasPrice together with a gasToken and refundReceiver makes the Safe pay a refund and call the token contract, so check all three before signing.