[Feature] Add support for ReceiveRecordInterceptor in MicroProfile module

[Aamir377300]

Description

While reviewing the ProtocolLayerClient implementation across different modules, I noticed a gap in the MicroProfile module.

In Spring-based setups, it’s possible to intercept transaction records using an optional ReceiveRecordInterceptor bean. However, this capability is currently missing in the MicroProfile module (e.g., Quarkus), which makes it difficult to implement consistent observability or metrics across frameworks.

Current Behavior

In the Spring module, the interceptor is optionally injected and applied:

@Bean
ProtocolLayerClient protocolLevelClient(
    final HieroContext hieroContext,
    @Autowired(required = false) final ReceiveRecordInterceptor interceptor) {
  ProtocolLayerClientImpl protocolLayerClient = new ProtocolLayerClientImpl(hieroContext);
  if (interceptor != null) {
    protocolLayerClient.setRecordInterceptor(interceptor);
  }
  return protocolLayerClient;
}

In contrast, the MicroProfile module does not provide any way to inject or use an interceptor:

@Produces
@ApplicationScoped
ProtocolLayerClient createProtocolLayerClient(@NonNull final HieroContext hieroContext) {
  return new ProtocolLayerClientImpl(hieroContext);
}

Problem

• There is no way to intercept transaction records in MicroProfile
• Metrics and observability features cannot be implemented consistently across frameworks
• Users cannot add custom logging, auditing, or monitoring logic

Proposed Solution

Update ClientProvider.java to optionally inject ReceiveRecordInterceptor using CDI’s Instance pattern.

@Inject
Instance<ReceiveRecordInterceptor> interceptors;

@Produces
@ApplicationScoped
ProtocolLayerClient createProtocolLayerClient(@NonNull final HieroContext hieroContext) {
    ProtocolLayerClientImpl client = new ProtocolLayerClientImpl(hieroContext);
    interceptors.stream().findFirst().ifPresent(client::setRecordInterceptor);
    return client;
}

This keeps the behavior optional (like Spring) while enabling extensibility.

Additional Observation

I also noticed a TODO related to missing UINT64 support. Since values may exceed Long.MAX_VALUE, it would be better to support this via BigInteger to ensure full compatibility with protocol numeric types.

please assign this issue to me and let me know if this approach looks good or if there are any preferred changes