investigate(flexible/databases): DatabaseBackupConfig has paired aliased fields (interval/backup_interval, time_utc/database_backup_time_utc, storage_type/backup_storage_type)

[joshrotenberg]

Summary

While documenting flexible/databases.rs::DatabaseBackupConfig field-by-field for the #80 rustdoc pass (#96), spotted three pairs of fields that look like wire-shape duplicates surfacing the same value under two different JSON keys:

Field A	Field B
interval	backup_interval
time_utc	database_backup_time_utc
storage_type	backup_storage_type

In the #96 PR these were documented as "server-returned alias for ..." to unblock the doc lint, but the underlying question remains: which form does the real API return on which path? Is one of them obsolete or only present on a specific endpoint variant (e.g. the embedded view inside a Database response vs a standalone backup-config response)?

Why this matters

If both fields can be populated simultaneously the doc framing is fine; if only one is populated at a time, callers reading the "wrong" field will silently see None even when the API supplied a value (same class of bug as #76 activatedOn).

Suggested investigation

1. Live validation against a real Cloud account: trigger a backup-config retrieval and inspect the raw response. Confirm which key the API actually emits.
2. If only one form is real, mark the other #[deprecated] (or drop it under a major bump) and update the docs to point at the canonical field.
3. If both can appear, document the conditions under which each is populated.

References

• Surfaced by docs(models): document fields in the four large request/response modules #96 (rustdoc field pass)
• Class of bug: silent data drop, see fix(flexible/databases): Database.activated should be activatedOn (silent data drop) #76 (activatedOn rename) and docs: OpenAPI spec deltas - fields missing from official spec #40 (spec deltas tracking)