microprofile: Implement ContractVerificationClient (Hashscan verify API)

### Summary
The MicroProfile module exposes `ContractVerificationClient`, but the current implementation is **incomplete**. Some methods are stubs, and the file-based check does not work end-to-end because it depends on an unimplemented path.

This issue is about delivering a **complete, usable** MicroProfile implementation so callers can use contract verification from this stack the same way they would expect from the interface contract.

### Current behavior
- `checkVerification(ContractId)` and `verify(...)` throw `UnsupportedOperationException`.
- The three-argument `checkVerification` method relies on `checkVerification(ContractId)`, so that flow cannot succeed as written.

### Goal
Implement **`ContractVerificationClient`** in the MicroProfile module so that **all methods** are implemented for normal use, with behavior and error handling that match the **interface and Javadoc** in `hiero-enterprise-base`.

### Acceptance criteria
- [ ] No `UnsupportedOperationException` on the public `ContractVerificationClient` API for the flows described in the interface.
- [ ] `checkVerification(ContractId)`, `verify(...)`, and `checkVerification(ContractId, fileName, fileContent)` are all usable end-to-end.
- [ ] Tests cover the main success and failure paths (approach left to the implementer: mocks, test HTTP server, etc.).

### References
- Interface: `hiero-enterprise-base/.../ContractVerificationClient.java`
- Current MicroProfile class: `hiero-enterprise-microprofile/.../ContractVerificationClientImpl.java`
- Spring reference: `hiero-enterprise-spring/.../ContractVerificationClientImplementation.java`

Start with hiero-enterprise-base/.../ContractVerificationClient.java and its Javadoc, then compare the stubs in hiero-enterprise-microprofile/.../ContractVerificationClientImpl.java with hiero-enterprise-spring/.../ContractVerificationClientImplementation.java. Add tests for the main success and failure paths using the chosen mocking or HTTP-server approach; done means all three named flows work without UnsupportedOperationException.

Written by the indexing model from the issue text.