Enable intent-based order flows and address handling in aggregator

[onahprosper]

User Story

As a user or developer, I want to enable intent-based order flows in the aggregator service, so that payment orders can leverage the new intent-based receive address and quoting mechanisms.

Acceptance Criteria

1. GIVEN the aggregator is configured,
   WHEN an intent-based order is initiated,
   THEN the system should validate required fields (such as slippage and return address), call the intent quote service, and update the receive address and transaction log with intent details.

2. GIVEN a user sends a payment with an intent-based order,
   WHEN the target network is Ethereum, Tron, Solana, or Bitcoin,
   THEN the return address must be validated for the specific network type.

3. GIVEN the intent quote service is called,
   WHEN the call fails,
   THEN a meaningful error message is returned to the user and logged.

4. GIVEN a successful intent quote,
   WHEN the deposit address is received,
   THEN it is stored as the intent address on the receive address entity and reflected in both metadata and transaction logs.

5. GIVEN a non-intent order is processed,
   WHEN the order flow continues,
   THEN it must not interact with intent-specific logic and must retain backward compatibility.

6. GIVEN a payment order is initiated,
   WHEN the metadata is constructed,
   THEN all relevant fields (including intent flags, slippage, intent and receive addresses) must be captured in the logs for traceability.

Tech Details

• Added support for intent-based orders in the payment flow:
• Added new IntentConfiguration in config/intent.go.
• Updated controllers to initialize and use clickDefuseService for intent quotes.
• Modified SenderController and Controller to handle new intent-based logic, including validation and downstream service calls.
• Updated ent schema for ReceiveAddress to include the intent_address field and methods.
• Ensured transaction logs and metadata capture intent-related information.
• PR: Feat/intent #474

Notes/Assumptions

• All changes are behind feature toggles where required and backward compatible.
• Integration is tested end-to-end within the aggregator context.

Open Questions