[9] Wire `LiquidityContractClient` into `LiquidityService`

[EmeditWeb]

Problem

src/modules/liquidity/liquidity.service.ts currently returns hardcoded placeholder XDR strings for deposit() and withdraw() operations. The real LiquidityContractClient exists in src/blockchain/contracts/ but is not injected, so the mobile app's sponsor flow cannot actually deposit on-chain.

Context

This is the sponsor-side blocker for end-to-end testing. Without real XDR generation, sponsors can sign but the resulting transaction is unsubmittable garbage. Every other sponsor feature (portfolio, APY, withdrawals) depends on this being real.

Before Starting

Read these context files first:

• context/architecture-context.md
• context/code-standards.md
• context/progress-tracker.md
• src/modules/liquidity/liquidity.service.ts
• src/blockchain/contracts/liquidity-contract.client.ts

What To Build

1. Inject LiquidityContractClient into LiquidityService constructor.
2. Read LIQUIDITY_POOL_CONTRACT_ID from ConfigService and pass to the client.
3. Replace placeholder in buildDepositXdr(walletAddress, amount): call client.buildUnsignedXdr('deposit', [walletAddress, amount]) and return the base64 XDR string.
4. Same for buildWithdrawXdr(walletAddress, shares): call client.buildUnsignedXdr('withdraw', [walletAddress, shares]).
5. Add error handling: contract simulation errors should return a 400 with the typed Soroban error code mapped to a user-facing message.
6. Update e2e test test/e2e/liquidity.e2e-spec.ts to assert the returned XDR is a valid base64-encoded Stellar transaction (use TransactionBuilder.fromXDR()).

Files To Touch

• src/modules/liquidity/liquidity.service.ts
• src/modules/liquidity/liquidity.module.ts
• src/blockchain/contracts/liquidity-contract.client.ts
• src/blockchain/blockchain.module.ts
• test/e2e/liquidity.e2e-spec.ts
• .env.example

Acceptance Criteria

• No placeholder XDR strings remain in the liquidity service
• Returned XDR parses successfully via TransactionBuilder.fromXDR
• LIQUIDITY_POOL_CONTRACT_ID is read via ConfigService, not process.env
• Contract simulation errors map to typed HTTP errors
• E2E test passes against a running Soroban testnet RPC
• Unit tests for the service mock the client and assert the right method is invoked

Mandatory Checks Before PR

• npm run build passes with zero TypeScript errors
• No new any types introduced anywhere
• Full Swagger @apioperation + @apiresponse decorators on any new endpoints
• New migration file created for any schema changes
• context/progress-tracker.md updated

[Vicsygold]

BOSS PLS I NEED THIS PROJECT

[Godfrey-Delight]

Hello maintainer, I would love to work on this issue. Please assign to me

[grantfox-oss]

🦊 GrantFox — @Godfrey-Delight has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #1)
2. Your PR will be reviewed by the StepFi-app maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@Godfrey-Delight's PR #94 was approved and merged by @EmeditWeb.

🏆 @Godfrey-Delight: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (729 total points). Track your full progress on GrantFox.

👏 Great work, @Godfrey-Delight! Keep contributing to StepFi-app.