chore(hub): drop vestigial `settings IS NOT NULL` guards on spaces

[wa0x6e]

Context

The spaces.settings JSON column is nullable, and the hub filters NULL-settings spaces in four places:

• apps/hub/src/graphql/operations/votes.ts:67,109
• apps/hub/src/graphql/operations/proposal.ts:21
• apps/hub/src/graphql/operations/subscriptions.ts:45

This is a relic from the era when a space row could exist before being configured. Today the sequencer write path (addOrUpdateSpace, apps/sequencer/src/helpers/actions.ts:26) refuses any space without settings.name and writes the settings JSON in the same INSERT — the NULL state is unreachable.

Verified on prod (PlanetScale): 0 of 91,766 spaces have settings IS NULL; settings.name key is present on every row.

The guard is also applied inconsistently: the main space listing (apps/hub/src/helpers/spaces.ts:164) and vp.ts only filter deleted = 0 — if NULL settings were still possible, those paths would break anyway.

Proposal

1. Backfill nothing (nothing to backfill), alter spaces.settings to NOT NULL.
2. Drop the four settings IS NOT NULL predicates.
3. Update apps/hub/src/helpers/schema.sql to match.

Related: this feeds the wider hub schema nullability tightening — with the column NOT NULL, formatSpace input is guaranteed and more Space GraphQL fields can become non-null.