Bug: Payment amount validation accepts malformed numeric strings

### Describe the bug

Payment amount validation accepts malformed numeric strings because validateStringAmount() uses parseFloat(). For example, parseFloat("1abc") returns 1, so the value can pass validation even though it is not a valid decimal amount.

### Steps

1. Open packages/account-sdk/src/interface/payment/utils/validation.ts
2. Check validateStringAmount()
3. Notice that it validates the amount using parseFloat(amount)
4. Try values like:
- "1abc"
- "1.2.3"
- "1foo"
5. These values can pass the initial numeric validation because parseFloat() accepts partial numeric strings
6. Later, the same value is passed toward payment encoding, where parseUnits() expects a valid decimal string

### Expected behavior

validateStringAmount() should reject malformed decimal strings immediately.

Valid examples should include:
- "1"
- "1.0"
- "1.000001"
- "10.50"

Invalid examples should include:
- "1abc"
- "1.2.3"
- "1foo"
- "abc"
- ""
- "."
- "1."
- "0"
- "-1"

### Version

2.5.6 / latest master

### Additional info

Suggested fix: replace parseFloat-based validation with strict decimal string validation.

Example:

```ts
export function validateStringAmount(amount: string, maxDecimals: number): void {
if (typeof amount !== 'string') {
throw new Error('Invalid amount: must be a string');
}

const pattern = new RegExp(`^(?:0|[1-9]\\d*)(?:\\.\\d{1,${maxDecimals}})?$`);

if (!pattern.test(amount)) {
throw new Error(
`Invalid amount: must be a positive decimal string with up to ${maxDecimals} decimal places`
);
}

if (Number(amount) <= 0) {
throw new Error('Invalid amount: must be greater than 0');
}
}
```

This would make SDK validation stricter and fail earlier with a clear error.

### Desktop

- OS: N/A
- Browser: N/A
- Version: N/A

### Smartphone

- Device: N/A
- OS: N/A
- Browser: N/A
- Version: N/A

Open packages/account-sdk/src/interface/payment/utils/validation.ts and inspect validateStringAmount(), starting with its parseFloat-based check. Exercise it with the valid and malformed examples listed in the issue, then replace the partial-number validation with strict decimal-string validation. Done means malformed, empty, zero, negative, and over-precision values are rejected before payment encoding, while the valid examples pass.

Written by the indexing model from the issue text.