Give locked HTTP batch items distinct audit receipts

[aruintelligence]

Problem

Locked HTTP batch evaluation selected one request timestamp and reused the runtime's deterministic default stream ID. Two identical intents in a batch therefore produced the same audit stream ID and receipt hash, making separate evaluations indistinguishable in the evidence.

Change

• Give each locked batch item a server-generated UUID and reject caller-supplied stream_ids alongside stream_id.
• Add validated per-item stream_ids to the direct batch API for trusted hosts, while retaining deterministic local defaults for fixed inputs and time.
• Declare the batch API in TypeScript and document the behavior in the locked HTTP guide and OpenAPI description.

Verification

The new HTTP regression failed on the previous implementation (32-character deterministic ID) and now checks distinct IDs, distinct receipt hashes, and valid receipts. The focused tests (43/43), full Node test suite, public contract and deployment surface checks, local link check, consumer compatibility, API stability, and upgrade contract checks pass.

Audit IDs distinguish evaluations; they do not establish caller identity or truthfulness of declared intent.