chore: Bump helidon version to 4.5.0

[derektriley]

Description:
This pull request updates the Helidon dependency and makes necessary adjustments to the gRPC client stream implementation to support the new version. The changes ensure compatibility with Helidon 4.5.0 by updating constructor signatures and usages to include the new required Http2ClientImpl parameter.

Dependency upgrade:

• Updated the Helidon dependency version from 4.4.1 to 4.5.0 in build.gradle.kts, preparing the project for the latest features and fixes.

Code changes for Helidon 4.5.0 compatibility:

• Modified the PbjGrpcClientStream class constructor to accept an additional Http2ClientImpl parameter and updated its call to the superclass constructor accordingly.
• Updated the instantiation of PbjGrpcClientStream in PbjGrpcClient.java to pass the new Http2ClientImpl argument as required by the updated Helidon API.
• Added the necessary import for Http2ClientImpl in PbjGrpcClientStream.java to support the new constructor parameter.

Fixes:

• BidiStreamingBuilderImpl.onComplete() calls incoming.onComplete() followed by super.onComplete(). The first call cascades
  through the user's handler → response converter → SendToClientSubscriber.onComplete(), which sends a HEADERS+END_STREAM
  trailer frame to the client. The super.onComplete() call then invokes SendToClientSubscriber.onComplete() a second time,
  sending a duplicate trailer frame.

  On the client side (Helidon 4.5.0), pushTrailers() detects the duplicate via inboundEndQueued and throws Http2Exception.
  This propagates up to the connection read loop's exception handler, which calls buffer.fail() on the stream's
  StreamBuffer. Because StreamBuffer.fail() causes all subsequent and currently-waiting poll() calls to throw immediately —
  even if unread DATA frames are already queued — the client's reply-reading loop dies after consuming only 1 of 3
  expected replies.

  The fix makes SendToClientSubscriber.onComplete() idempotent with an AtomicBoolean guard. The framework's safety-net
  behavior (calling replies.onComplete() via super.onComplete() in case the user's handler doesn't) is preserved for
  handlers that don't call it themselves; duplicate calls from handlers that do are now no-ops.

Test code cleanup:

• Removed a redundant verification in the testCreatePbjGrpcClientStream test, as the stream ID behavior has changed or is no longer relevant.

Related issue(s):

Fixes #863

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[github-actions]

JUnit Test Report

   521 files  ±0     521 suites  ±0   25s ⏱️ -2s
 1 537 tests ±0   1 533 ✅ ±0   4 💤 ±0  0 ❌ ±0 
10 755 runs  ±0  10 727 ✅ ±0  28 💤 ±0  0 ❌ ±0 

Results for commit 53d28ac. ± Comparison against base commit 0811336.

♻️ This comment has been updated with latest results.

[github-actions]

Integration Test Report

    428 files  ±0      428 suites  ±0   16m 21s ⏱️ + 1m 28s
115 048 tests ±0  115 048 ✅ ±0  0 💤 ±0  0 ❌ ±0 
115 292 runs  ±0  115 292 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 53d28ac. ± Comparison against base commit 0811336.

♻️ This comment has been updated with latest results.

integ tests failed

[alex-kuzmin-hg]

Looks OK. I'll run full SDPT after new BN tag