#124 [High] Implement multi-hop route composition in `RoutingService`

[james2177]

Description: src/routing/routing.service.ts currently implements exactly one method, createDirectRoute(), which always produces a single-step Route with a hardcoded estimatedTime: 60 and estimatedGas: "0" — there is no logic for composing a multi-hop route (e.g. source-chain bridge/swap step followed by a Stellar-side fill) even though the Route/RouteStep types it returns (src/intents/intents.types.ts) are already generically shaped to support multiple steps.

Problem Statement & Context: Issue #7 wires RoutingService into the intent creation/quote flow and issue #13 filters quotes by solver capability, but both assume RoutingService produces a correct route — today it always returns the same trivial direct-solver-transfer shape regardless of whether a better (cheaper, faster) multi-hop path exists. This leaves real routing logic as the single biggest gap in the "routing" subsystem's name.

Scope & Acceptance Criteria:

• Add a route-composition method that can produce a multi-step Route (e.g. source-chain step + Stellar-side step) when a direct solver path isn't the best option, using the existing RouteStep/Route types unchanged.
• Add real (non-hardcoded) estimatedTime/estimatedGas/totalFeesUSD/priceImpact calculation, replacing the current always-0/always-60 placeholders, informed by whatever token/solver data is realistically available (src/tokens/tokens.service.ts, src/solvers/solvers.service.ts).
• Out of scope: integrating with any external bridging/DEX aggregator API — model multi-hop composition using the protocol's own solver network only; external liquidity-source integration is a larger, separate effort.
• Out of scope: the wiring of RoutingService into the controller/service flow — that's issue feat: add SolversModule (service + controller) #7's scope; this issue only makes the routing logic itself non-trivial.

Implementation Guidelines:

1. Key files: src/routing/routing.service.ts, src/routing/routing.module.ts, src/intents/intents.types.ts (Route, RouteStep type definitions), src/solvers/solvers.service.ts, src/tokens/tokens.service.ts.
2. Design a clear decision boundary for when a direct route suffices versus when multi-hop composition is attempted (e.g. based on solver capability match from issue test: unit tests for IntentsService, SolversService, TokensService #13's filtering work) — document the chosen heuristic since "optimal routing" is an open-ended problem and this issue should scope to a defensible, testable heuristic rather than true optimization.
3. Preserve backward compatibility for existing callers of createDirectRoute() (keep it as a valid code path/fallback) rather than replacing it outright, since other in-flight issues may depend on its current signature.
4. Testing: minimum 85% coverage on the new composition logic; add test cases for direct-route-still-best, multi-hop-required, and no-viable-route scenarios, plus verification that computed estimatedTime/estimatedGas/totalFeesUSD are no longer hardcoded placeholders.

Definition of Done:

• Multi-hop composition implemented, real cost/time estimation added, backward compatibility preserved.
• Acceptance criteria met.
• PR passes CI with test output.
• Reviewed and approved.

Resources: src/routing/routing.service.ts, src/intents/intents.types.ts, src/solvers/solvers.service.ts, src/tokens/tokens.service.ts

Complexity: High (200 points)