project(sidecar): Add oracle attestation endpoint on signature aggregator (handler ID 4)

[boraerincplusplus]

NOTE: (PR2)

This is a draft, not to be merged just yet. I'm opening this up to mark it for review.

Why this should be merged

The signature aggregator previously hardcoded handler ID 2 (SignatureRequestHandlerID) on every AppRequest it sends to validators. Originally I had created another aggregator, but the only thing different between that one and this one was the handler ID. After some discussions with @geoff-vball we decided it was fine to be a bit more invasive. This PR modifies signature aggregation to accept an explicit handler ID, updates existing call sites to pass 2 (standard warp), and adds a new /oracle/aggregate-signatures endpoint that passes 4, routing validator AppRequests to the oracle verifier instead of the native warp handler.

How this works

CreateSignedMessage previously hardcoded the p2p handler ID in marshalRequest. This PR adds handlerID uint64 as an explicit parameter so callers control which validator handler processes their signing request.

A new HTTP endpoint /oracle/aggregate-signatures is registered alongside the existing /aggregate-signatures. It accepts the same request/response format but passes OracleHandlerID = 4 to CreateSignedMessage, so the protocol prefix on each AppRequest tells validators to dispatch to their oracle verifier rather than the native warp handler.

How this was tested

Existing aggregator unit tests updated to pass the handler ID explicitly and continue to pass.

How is this documented

The oracle_api.go file describes the endpoint, its expected request format (justification = hex-encoded Solana transaction signature), and how it differs from the standard endpoint