Fix authenticated CHIRP HEAD responses in UHRP hosts

[ty-everett]

Authenticated CHIRP staged-object HEAD responses signed a text or JSON body that HTTP suppressed. AuthFetch therefore rejected present, missing, and invalid-object responses before an uploader could PUT its closure. Send and sign an empty body for HEAD responses in both the canonical Lite handler and its Cloud Bucket copy; other methods keep their existing response formats.

Program and scope

• Tracker: operational UHRP recovery; BotBoard 644.
• Program gates advanced: authenticated CHIRP publication interoperability and synchronized service runtime.
• Why needed: a real staging publish stopped on its first authenticated HEAD with Signature is not valid.
• Out of scope: authentication policy, payments, storage schemas, dependency graph, and public npm packages.
• Exact head SHA reviewed locally: e0ad6d9e88fbe15e71092c2c88370f3f5d656056; all 39 exact-head checks terminal and successful or scope-validated by the successful merge gate.

Impact

• No public package source or manifest changed
• Infrastructure source, dependency, image, or deployment configuration changed
• Security-sensitive boundary changed
• Documentation or examples changed

Service image patches: UHRP Lite 0.1.44 and Cloud Bucket 0.2.47. No client or persisted-data migration is required. Status codes are preserved; HEAD error bodies now follow HTTP semantics.

Verification

• Real Express/BRC-103/AuthFetch HTTP regression: present 200, absent 404, invalid identifier 400. All three fail against the prior Cloud handler with signature errors and pass with the fix; a matching Lite regression also passes. Both HTTP fixtures use the actual service pre-authentication and identity rate-limit policies.
• Node 24 Cloud build, lint and full test suite: 18 suites / 95 tests passed. Lite build, lint and full test suite: 12 suites / 90 tests passed.
• Root frozen install, audited esbuild rebuild, workspace build, typecheck, lint, format and health checks completed locally. Changed source formatting and runtime-copy synchronization checked separately.
• Runtime dependency audits: zero findings in both services. Locks change only the two top-level service version fields, with no graph changes.
• Hosted CI 36288052122, CodeQL 36288052100 and container runtime 36288052168 succeeded. All 39 exact-head checks are terminal and accepted by the merge gate.
• Conformance: HTTP-level authentication verifies signed responses and the actual caller identity without mocking cryptography; no BSV wire encoding or public package contract changes.
• Coverage: six additional HTTP cases across both service contexts. No skipped tests or coverage exclusions added.
• Browser/mobile/packed consumers: SDK AuthFetch is exercised over real HTTP; final live CHIRP and modern UI acceptance remain deployment gates.
• Performance: no additional request, parsing, storage or cryptographic work; no bundle dependency change.
• I self-reviewed the complete diff for correctness, security, compatibility, API, artifacts, dependencies, docs, and operations

Security and dependencies

• Changelog, runtime relevance, peer compatibility, transitive graph, and audit results were reviewed
• Negative tests cover the changed response authentication boundary
• No new override, advisory dismissal, quality suppression, or skipped test
• Workflow permissions and lifecycle-script behavior remain least privilege
• CodeQL: zero open PR alerts after successful analysis; the first-head fixture alerts are fixed by using the actual service rate limits. Exact-head Sonar: quality OK, zero new findings (including accepted/false-positive states) and zero unreviewed hotspots.

Dependency evidence

• Necessity: no dependency upgrade; service metadata only.
• Runtime/build/peer compatibility: Node 24, existing locked SDK 2.8.8 and middleware; both contexts pass build/tests.
• Deduplicated lockfile: dependency graph unchanged.
• Audit and CodeQL: local audits have zero findings; successful hosted CodeQL analysis and zero open PR alerts.
• Public package versions and packed consumers: not applicable to these separately released service images.

Release and operations

• No npm publication was performed from a workstation or from this PR
• Required service patch bumps are included
• Image/SBOM/provenance/deployment/rollback impact is documented
• Documentation and migration guidance are current
• Publish only through protected infrastructure release from reviewed main, verify immutable Linux/amd64 images/signatures/SBOMs/provenance, then promote Cloud Bucket staging-first. Production must use the same accepted digest. An older image remains the rollback reference; rollback restores the known CHIRP defect and requires reassessment.

Completion evidence

• Exact-head CI, zero alerts/findings/hotspots, no review threads, and qualified maintainer full-diff review are recorded.
• One qualified maintainer approval is sufficient under the root policy; no last-pusher restriction is assumed.
• This source PR does not claim successful image publication or live CHIRP acceptance.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ty-everett]

Maintainer review accepted exact head e0ad6d9e88fbe15e71092c2c88370f3f5d656056. The complete diff preserves identity authorization and status codes, signs the empty bytes that HEAD actually sends, leaves other error formats unchanged, synchronizes the canonical runtime copy, and includes current service documentation and patch versions. Both real HTTP fixtures use the service pre-authentication and identity rate limits. Local full suites passed 95 Cloud and 90 Lite tests; the six HTTP cases also pass after that fixture change. All 39 exact-head checks are terminal and accepted, CodeQL has zero open PR alerts, Sonar reports zero new findings and unreviewed hotspots, and there are no review threads. Protected image publication and staging-first live CHIRP acceptance remain separate gates.