fix(base): expirationTime on large FileClient.createFile

[alejandroGM0]

Problem

FileClientImpl.createFile(byte[], Instant) silently drops the user-provided
expirationTime whenever the payload exceeds FileCreateRequest.FILE_CREATE_MAX_SIZE.

In createFileImpl, the small-file branch correctly picks between
FileCreateRequest.of(contents) and
FileCreateRequest.of(contents, expirationTime)
based on whether an expiration was supplied.

The multi-append branch unconditionally calls the one-arg factory:

final byte[] start = Arrays.copyOf(contents, FileCreateRequest.FILE_CREATE_MAX_SIZE);
final FileCreateRequest request = FileCreateRequest.of(start); // expirationTime dropped

FileCreateRequest.of(byte[]) hardcodes expirationTime = null, and
ProtocolLayerClientImpl.executeFileCreateTransaction only calls
FileCreateTransaction.setExpirationTime(...) when the request's expiration is non-null.

The result is that the underlying SDK transaction never receives the requested expiration,
so the created file falls back to the SDK/network default rather than the caller's value.

The expirationTime parameter is even validated earlier in the method
("must be in the future") before being silently discarded in this branch, which makes
the bug especially misleading.

---

Fix

Mirror the small-file branching logic in the multi-append branch so the initial
FileCreate transaction carries the caller-supplied expirationTime when present.

No changes to the append path are needed — FileAppend transactions do not accept
an expiration.

---

Test

Adds testCreateFileWithExpirationForSizeGreaterThanFileCreateMaxSize, which:

• calls createFile(content, expirationTime) with
  content.length == FILE_CREATE_MAX_SIZE * 2
• verifies the FileCreateRequest handed to ProtocolLayerClient carries the requested
  expirationTime
  (argThat(request -> expirationTime.equals(request.expirationTime())))
• verifies the expected number of FileAppend transactions follow

All FileClientImplTest unit tests pass.