feat!: carry the generation verdict on a manifest page

[mfw78]

Closes #5.

An empty manifest page already carried reasonCode, so the issue is not entirely as written. But reasonCode is the selector of an error the handler declares (TooEarly.selector, OrderNotInitialized.selector), so a consumer that has not been taught a particular handler's error names still cannot tell a not-yet-active order from a permanently invalid one. Both render as "no orders". The verdict and the wait timestamp were both decoded by _decodeErrorToGeneratorResult and then discarded on the way out.

The change

getManifestPage returns a ManifestStatus in place of the bare selector:

struct ManifestStatus {
    IConditionalOrderGenerator.GeneratorResultCode code;
    uint256 waitUntil;
    bytes4 reasonCode;
}

code is the same verdict poll would return for the same conditions, decoded through the same _decodeErrorToGeneratorResult. The manifest mirrors the poll path rather than becoming a second source of truth for whether an order is live. reasonCode is unchanged and remains the handler-declared detail, useful once a consumer does know the handler.

An ordinary page reports POST with zeroes, including a page that is empty only because offset is past the end. That is what separates "nothing here" from "nothing yet": both return no entries, and only code distinguishes them.

All three implementations move together

Two helpers on BaseConditionalOrder, _manifestOk() and _manifestStatus(errorData), so the error-to-status mapping is stated once. TWAP and PerpetualStableSwap call them rather than restating it, which is what keeps the three from drifting apart later.

TWAP's uninitialised-context page now reports TRY_NEXT_BLOCK rather than an unqualified empty page. A context that has not been written yet is transient, and reporting it as an ordinary empty page is the same conflation the issue is about.

Breaking

getManifestPage's third return value changes type. #46 established there are no deployments, so no consumer is affected; that is the reason for doing this now rather than adding a parallel accessor.

Verification

166 tests pass, forge fmt --check clean, forge build clean.

The two assertions that carry this change were checked against an implementation that decodes the verdict and then discards it, keeping only reasonCode (the old behaviour):

mutation applied: verdict discarded, reasonCode kept
  test_manifestPage_EmptyPageCarriesWaitReason:    FAIL
  test_manifestPage_EmptyPageCarriesInvalidReason: FAIL
restored: 166 tests passed

Both fail without the fix, so they are testing the behaviour rather than passing either way.

How to test

export FOUNDRY_PROFILE=ci
forge fmt --check && forge build && forge test --no-match-test fork --fuzz-seed 672679878