fix: align go inscriber auth with TypeScript parity

[kantorcodes]

Summary

• remove session token forwarding from the Go inscriber client surface to match the TypeScript inscriber implementation
• keep the verified HCS-27 inscription path green after the cleanup
• retain focused header coverage proving only the API key is forwarded by the client

Verification

• go test ./pkg/inscriber ./pkg/hcs27 -count=1
• RUN_INTEGRATION=1 RUN_INSCRIBER_INTEGRATION=1 go test ./pkg/inscriber -run TestInscriberIntegration_AuthStartExecute -count=1 -v
• RUN_INTEGRATION=1 RUN_INSCRIBER_INTEGRATION=1 go test ./pkg/inscriber -run TestInscriberIntegration_HighLevelInscribe_DefaultWebSocket -count=1 -v
• RUN_INTEGRATION=1 go test ./pkg/hcs27 -run TestHCS27Integration_MetadataOverflowUsesHRL -count=1 -v

Notes

• Live verification used the funded testnet operator account 0.0.2656337.
• The inscription service still uses custodial payer 0.0.2659396 in the returned transaction IDs, which is expected upstream behavior and not the operator account used by the SDK.

[gemini-code-assist]

Code Review

This pull request introduces new transaction execution strategies for the Hedera inscriber, including direct gRPC submission of serialized transactions and a pass-through execution mode. It also refactors authentication header handling and expands private key parsing capabilities. Key feedback includes addressing a potential nil pointer panic when appending signatures, fixing redundant error reporting logic, and improving security by avoiding hardcoded insecure TLS verification. Additionally, the reviewer noted that hardcoding node addresses is brittle and should be replaced with a more robust discovery mechanism.

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
pkg/inscriber/client.go	441, 447	Duplicate condition check for INVALID_SIGNATURE error - both lines check identical condition and will execute together when error contains "INVALID_SIGNATURE", causing duplicate error logging.

Files Reviewed (1 files)

• pkg/inscriber/client.go - 1 issue

---

_{Reviewed by minimax-m2.5-20260211 · 68,078 tokens}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f25d91fdb0

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 72b2e81fb3

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Avoid failing after successful precheck on receipt lookup errors

Once CryptoTransfer returns OK, the transaction is already accepted by a node, but this block immediately returns an error if the first receipt query fails (for example RECEIPT_NOT_FOUND, transient node lag, or a tight context deadline). ExecuteTransaction then falls through to other execution strategies and can surface a hard failure (often duplicate-precheck errors) even though the original submission later reaches consensus, so callers can be told the transfer failed when it actually succeeded.

Useful? React with 👍 / 👎.