chore: regenerate against the v1.7.8 API surface

[jfrench9]

What

One behavioural change, two documentation ones.

StorageSummary.total_gb_hours removed

The server retired it in robosystems#1107. It was a storage-billing unit, and there is no storage billing — the overage column is never written, the billing config has no storage entries, and storage is included in the tier. The field described a mechanism that had been removed.

avg_storage_gb is now documented as time-weighted, which is what it became: each reading weighted by the span since the previous one, so an irregular snapshot cadence doesn't skew it.

Docstrings only

From robosystems#1105: restore is allowed on entity subgraphs — they're written directly and have no materialization path, so a subgraph has no other recovery route. Touches restore_backup and backup_list_response.

On the version

This removes a field from a response model, which the 1.0 contract would normally make a major. It rides as a patch deliberately:

The server change already shipped. The field is gone from the API, so a client still declaring it would be describing a response it can never receive. There's nothing to deprecate-then-remove — the client is catching up to the wire, not initiating the break. A deprecation cycle only makes sense when you control removal timing on both sides.

Worth knowing rather than assuming: if you'd want strictness here, the lever is server-side sequencing — deprecate the field in the API first, then remove it a cycle later, and the client follows in step.

No known consumer reads it (robosystems-app greps clean).

Gate

519 passed, 17 skipped. ruff check + ruff format --check + basedpyright all clean.