feat(wallet-api): send token by email via JWT action token (#457)

[samwel141]

Description

Implements #457: send tokens to a future account holder via a signed, expiring JWT action token.

Two endpoints, both behind the existing api-key and JWT auth:

• POST /action-tokens : issue a token for tokens: [ids] or bundle: { bundle_size }
• POST /action-tokens/redeem : verify and execute the transfer

Issue(s) addressed

• Resolves Experiment: use JWT action token to implement the feature of 'send token by email adress' #457

What kind of change(s) does this PR introduce?

• Enhancement
• Bug fix
• Refactor

Please check if the PR fulfils these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Issue

What is the current behavior?
Token transfers require both the sender and receiver wallets to already exist;
there is no way to send tokens to someone who has not registered yet.

What is the new behavior?

• Issue a signed action token (RS256, issuer greenstand, default 7-day TTL)
  describing the sender wallet and the token ids to transfer.
• Redeem it from any authenticated wallet: the signed token is the
  authorization, so the named tokens move sender to redeemer as a single,
  atomic completed transfer.
• Expired, tampered, wrong-issuer, or wrong-type tokens are denied 401.
• If the sender no longer owns a listed token at redeem time, it fails 409
  with no partial transfer (accepted-risk case; no escrow in v1).
• Integration tests cover the issue→redeem happy path and expiry denial.

Breaking change

Does this PR introduce a breaking change?
No.

Other useful information

Scope intentionally limited per the issue discussion:

• No escrow / pending-hold of tokens at issue time (owner keeps custody)
• Bearer model: possession of the token authorizes redemption; the recipient
  email (sub) is informational
• No email delivery, one-time-use, or revocation in this version