fix: a null current round takes down the whole home page payload

Nobody has claimed this yet.

`getOrchestrators` (`lib/api/ssr.ts:84-107`) passes the subgraph's current round straight into the orchestrators query without checking it:

```ts
variables: {
currentRound: protocolResponse?.data?.protocol?.currentRound?.id,
currentRoundString: protocolResponse?.data?.protocol?.currentRound?.id,
}
```

When the subgraph returns no `protocol`, that is `null`, and `queries/orchestrators.graphql:12` sends `activationRound_lte: null`. Indexers reject it:

```
bad indexers: {0x…: BadResponse(unattestable response: Store error:
unsupported filter `<=` for value `null`), …}
```

`getOrchestrators` is the first call in the `try` block of `pages/index.tsx:680-728`, so orchestrators, events, protocol and gateways all fail together and the page falls back to `hadError`.

Two problems: the query is knowingly invalid and burns gateway credits, and the error message points at indexer health rather than the actual cause.

## Fix

Guard before querying — fail fast with a clear message, or skip the filter — so a missing round cannot reach the gateway.

## Related

`queries/orchestrators.graphql` is the only query with a `<=` filter bound to a variable, so this is the sole path that produces that error.

Start in lib/api/ssr.ts:84-107 and inspect how pages/index.tsx:680-728 calls getOrchestrators, then review the currentRound variable in queries/orchestrators.graphql:12. Reproduce the missing-protocol path and ensure a null round is stopped before the gateway query, with an error or query behavior that clearly reflects the missing round rather than indexer health.

Written by the indexing model from the issue text.