Fix file descriptor leak in GCP FGetObject on error paths

[SebTardif]

Summary

objectFile opened with os.OpenFile in GCSClient.FGetObject is only closed on the happy path. If NewReader or io.Copy fails, the file descriptor leaks.

Fix

Close objectFile on each error path with checked close errors, matching the pattern used by the Azure BlobClient.FGetObject implementation (blob.go:328-336).

The initial version used defer objectFile.Close(), which CodeQL flagged as discarding the close error on a writable file handle (code-scanning/6). The updated fix uses explicit close-on-error instead, consistent with the existing Azure pattern.

Error paths fixed

Error path	Before	After
NewReader fails	fd leaks	objectFile.Close() called, error logged
io.Copy fails	fd leaks	objectFile.Close() called, error logged
Happy path	objectFile.Close() checked	unchanged

Origin

The leak was introduced in #434 (2021-09-01) when GCS support was added.

[matheuscscp]

@SebTardif @hiddeco This looks concerning

[hiddeco]

Would be solved by something like:

Suggested change

	defer objectFile.Close()
	defer func() {
	if closeErr := objectFile.Close(); closeErr != nil && err == nil {
	err = closeErr
	}
	}()

[SebTardif]

Good catch. The bare defer objectFile.Close() was wrong for a writable handle. I've replaced it with explicit close-on-error on both failure paths, matching the Azure BlobClient.FGetObject pattern (blob.go:328-336). Close errors are now logged instead of silently discarded.