Enhancement: QueryOffsetResponse treats NO_OFFSET (0x13) as an error — first-run resume throws

[s2x]

Description

The server replies response_code = NO_OFFSET (0x13) for QueryOffset when no tracking record exists for the reference — a normal, expected answer (verified in rabbit_stream_reader.erl: osiris:read_tracking(...) undefined -> {?RESPONSE_CODE_NO_OFFSET, 0}). The Java client returns a QueryOffsetResponse carrying getResponseCode() and lets the caller decide.

The PHP response parses the code through assertResponseCodeOk(), which throws ProtocolException on anything non-OK:

self::assertResponseCodeOk($buffer->getUint16());
$offset = $buffer->getUint64();

So callers following the README "resume from the stored offset" flow hit an exception on first run (before any offset has ever been stored) instead of a sentinel.

Where

• src/Response/QueryOffsetResponseV1.php:35 (assertResponseCodeOk)
• reached via src/Client/Connection.php:262-270 (queryOffset()) and Consumer::queryOffset()

Suggested fix

Treat NO_OFFSET specially — return null/-1 or a dedicated result instead of throwing. If keeping the throw for BC, document it explicitly and rely on ProtocolException::getResponseCode() (already available) so callers can distinguish it. Note: behavior is currently pinned by tests/E2E/StoreOffsetQueryOffsetE2ETest.php:56-59, so changing it is a deliberate behavior change.