fix: size boot disks from the image instead of failing

[tas50]

What

When a disk is cloned from an image, look up the image's own size and raise the requested size to meet it, logging that it happened.

Why

The driver hardcodes a 10 GB default boot disk. GCE refuses to create a disk smaller than the image it is cloned from, so every image larger than 10 GB fails at create with stock configuration:

Google::Apis::ClientError: invalid: Invalid value for field
'resource.disks[0].initializeParams.diskSizeGb': '10'. Requested disk
size cannot be smaller than the image size (50 GB)

Current sizes of the stock images this affects:

image family	size	with disk_size unset
ubuntu-2204-lts	10 GB	ok
debian-12	10 GB	ok
rocky-linux-9	20 GB	fails
centos-stream-9	20 GB	fails
windows-2022	50 GB	fails
windows-2025	50 GB	fails

Every Windows image is 50 GB. That means the driver's Windows support — the email option, the WinRM startup script, and the whole password-reset path added in 3.0.0 — could not be reached at all unless the user first worked out on their own that they had to set disk_size by hand. There is nothing in the README that says so.

Approach

Failing over a size the user never chose is not useful, and GCE cannot honour a smaller value under any circumstances, so the driver corrects it and says what it did:

$$$$$$ Requested disk size of 10 GB is smaller than image
       windows-server-2022-dc-v20260814 (50 GB) - creating a 50 GB disk instead.
       Creating a 50 GB boot disk named tk-windows-windows-2022-2b2885-disk1 ...

An explicitly configured size larger than the image is honoured untouched. The same treatment is applied to extra disks built from a custom_image, which carry the identical constraint. Image sizes are memoised per name, and a lookup failure falls back to the configured value rather than raising.

Verification

Against real GCE. Before this change rocky-9 and windows-2022 both fail at create; after it, both complete the full kitchen test cycle with no disk configuration at all:

Creating a 20 GB boot disk named tk-default-rocky-9-2350bb-disk1 from image rocky-linux-9-v20260813...
...
Profile Summary: 2 successful controls, 0 control failures, 0 controls skipped
Finished testing <default-rocky-9> (1m50.44s).

Unit coverage added for: no size requested, a smaller size requested, a larger size requested, a custom_image extra disk, and an image that reports no size.

🤖 Generated with Claude Code

[tas50]

Heads-up on ordering with #150, which is open against the same disk documentation.

The Ruby merges cleanly — #150 changes DISK_DEFAULT_CONFIG and its comment, this PR changes create_local_disk and adds two helpers below it. The only conflict is in README.md, and it is purely mechanical: each PR edits a different row of the same two tables, and git cannot split adjacent lines.

Resolution is to take the disk_size row from this PR and the disk_type row from #150:

| `disks.<name>.disk_size` | `10` | Size in GB. Raised automatically when the image it is created from is larger. Must be omitted for `local-ssd`, which is always 375 GB. |
| `disks.<name>.disk_type` | *chosen by GCE* | Disk type, e.g. `pd-balanced`, `pd-ssd`, `hyperdisk-balanced`, `local-ssd`. See [disk types and machine series](#disk-types-and-machine-series). |

and the same pairing in the deprecated-options table. I test-merged the two branches with that resolution locally: bundle exec rake passes, 304 examples, 0 failures, no cookstyle offenses. Happy to rebase this branch onto #150 once that one lands, or the other way round — whichever you prefer.

[tas50]

Rebased onto main now that #150 has landed, so this is a single commit on top of 3.0.1 with no merge commit.

The only conflict was the one predicted above, in README.md. Resolved as described — disk_size row from this PR, disk_type row from #150:

| `disks.<name>.disk_size` | `10` | Size in GB. Raised automatically when the image it is created from is larger. Must be omitted for `local-ssd`, which is always 375 GB. |
| `disks.<name>.disk_type` | *chosen by GCE* | Disk type, e.g. `pd-balanced`, `pd-ssd`, `hyperdisk-balanced`, `local-ssd`. See [disk types and machine series](#disk-types-and-machine-series). |

The Ruby merged without conflict, and the two changes compose the way you would want — #150 guards disk_type so GCE picks it, this PR sets disk_size_gb per branch. They touch different attributes of the same params object:

params.disk_type = disk_type_url_for(disk_config[:disk_type]) if disk_config[:disk_type]
...
elsif disk.boot
  params.disk_size_gb = disk_size_for_image(disk_config[:disk_size], image_name)

Re-verified against live GCE on the rebased branch rather than assuming, since main moved underneath it. Both the raised and the untouched case, and the disk type now coming from GCE rather than the driver:

Creating a 20 GB boot disk named tk-default-rocky-10-7e153e-disk1 from image rocky-linux-10-v20260813...
Creating a 10 GB boot disk named tk-default-ubuntu-2404-0c4690-disk1 from image ubuntu-2404-noble-amd64-v20260820...

NAME                              SIZE_GB  TYPE
tk-default-rocky-10-7e153e-disk1  20       pd-standard

Local bundle exec rake: 308 examples, 0 failures, no cookstyle offenses. Both instances destroyed; the project has no leftover resources.