physical restore: pass custom flags to wal-g and pgBackRest

Problem

Physical restore builds the restorer command with no room for extra flags:

• internal/retrieval/engine/postgres/physical/wal_g.go:52 — wal-g backup-fetch <pgdata> <backupName>, nothing appendable
• internal/retrieval/engine/postgres/physical/pgbackrest.go:37 — pgbackrest restore plus a conditional --delta

Anything the restorer supports but DBLab does not model is unreachable. For wal-g this is not covered by options.envs: --restore-spec, --mask, --restore-only and --target-storage are registered as flags only (cmd/pg/backup_fetch.go upstream), unlike --reverse-unpack / --skip-redundant-tars, which fall back to WALG_USE_REVERSE_UNPACK / WALG_SKIP_REDUNDANT_TARS.

The only workaround is tool: customTool, which discards the whole integration — LATEST to real backup name resolution in walg.Init (#365 (closed)), the recovery config from GetRecoveryConfig (restore_command, plus recovery_target_timeline for PG < 12), and the pool-derived PGDATA path all have to be hand-rolled and re-hardcoded.

Proposal

customOptions: []string on both restorers, appended verbatim to the built command. Same shape as logical mode already has in logicalDump.options.customOptions / logicalRestore.options.customOptions (logical/dump.go:761, logical/restore.go:881).

physicalRestore:
  options:
    tool: walg
    walg:
      backupName: LATEST
      customOptions:
        - "--restore-only=mydb"

Unset or empty produces a byte-identical command, so existing configs are unaffected.

Scope

YAML only — no ConfigProjection field, no guardModeFields entry, no UI type. Physical mode is expert-level and already hand-edited; a free-form flag list in a web form is support burden with no upside.

Flags are passed through unvalidated. For pgBackRest they must not repeat an option the command already sets (--type, --stanza, --pg1-path, --recovery-option).