refactor(adapter-stellar): extract shared Soroban RPC server factory

Summary

The Stellar adapter (packages/adapter-stellar/) has 7 independent RPC/network client creation sites, with 5 near-identical getSorobanRpcServer implementations copy-pasted across files. This is a DRY violation that also causes inconsistent behavior — some call sites skip userRpcConfigService and allowHttp, meaning they won't respect user RPC overrides or work on localhost.

Duplication Map

Sites 1, 2, 4, 5 are virtually identical. Site 3 (relayer) and site 6 (access-control) skip userRpcConfigService, which means user RPC overrides are silently ignored. Site 6 also skips allowHttp, breaking localhost development.

Proposed Solution

1. Create a shared createSorobanRpcServer(networkConfig) utility (e.g. in configuration/rpc.ts or a new utils/soroban-client.ts) that:

   • Resolves RPC URL via userRpcConfigService with fallback to networkConfig.sorobanRpcUrl
   • Applies allowHttp for localhost URLs
   • Returns StellarRpc.Server

2. Replace all 6 Server creation sites with the shared utility

3. Align relayer.ts and access-control/onchain-reader.ts to use userRpcConfigService (bug fix)

Context

This was identified while doing the same refactor on the EVM adapter (createEvmPublicClient utility in utils/public-client.ts on branch 011-evm-access-control). The EVM side is already consolidated.

Start by comparing the six Stellar RPC Server creation sites listed in transaction/sender.ts, transaction/eoa.ts, transaction/relayer.ts, query/handler.ts, contract/type.ts, and access-control/onchain-reader.ts. Read the existing EVM createEvmPublicClient utility in utils/public-client.ts and inspect the userRpcConfigService and networkConfig usage. Done means the six sites use one shared factory, including user RPC overrides and localhost allowHttp behavior.