settings get hard-fails on updateSchedule.hours typed number but stored as string (spec/back-end)

## Bug

`growthbook settings get` hard-fails when org settings contain `updateSchedule.hours` stored as a **string** (e.g. `"7"` — real data in dev Mongo): `cannot unmarshal string into Go ... of type float64`. Affects `pretty` / `yaml` / `toon` (including agent-mode toon, the default for agents). `-o json` (skip-deserialization) works.

## Root cause (spec / back-end — NOT Speakeasy)

The generated OpenAPI spec types `updateSchedule.hours` as `anyOf: [number, null]`, but the back-end can serialize it as a string. The upstream fix belongs in the back-end: type `hours` as a number and coerce the stored value (packages/back-end Zod validators → `generated/spec.yaml`), or persist a number.

## Stopgap fix (retire when upstream is fixed)

`.speakeasy/patches/internal/cli/settings/getsettings.go.patch` + the `output.GenericFromRawBody` / `output.IsResponseDecodeError` helpers (in `output.go.patch`): on a response-decode error, `settings get` re-fetches with skip-deserialization and outputs the raw body via a lenient generic decode, so it succeeds in every format instead of hard-failing. Pairs with the agent-mode `response_error` classification (separate issue).

**To retire:** once the spec types `hours` to tolerate the value (and the back-end returns/coerces a number), drop the fallback hunk.

## Refs

- Introduced by #23
- Upstream: **growthbook back-end**, not Speakeasy — the spec is generated from `packages/back-end` Zod. This is a growthbook/cli tracking issue for retiring the CLI stopgap.

Start with .speakeasy/patches/internal/cli/settings/getsettings.go.patch and output.go.patch, then inspect the generated/spec.yaml and the back-end Zod validators mentioned in the issue. Confirm that updateSchedule.hours is typed to tolerate the stored value and that the back-end returns or coerces a number; once that is true, retire the CLI fallback hunk.

Written by the indexing model from the issue text.