Location returned by createFile omits the bucket when a custom endpoint is configured

New Issue Checklist

• Report security issues confidentially.
• Any contribution is under this license.
• Before posting search existing issues.

Issue Description

When a custom endpoint is configured through s3overrides.endpoint, the Location returned by createFile() omits the bucket, so it points at a path that does not exist on the storage host.

createFile() builds the location as:

const endpoint = this._endpoint || `https://${this._bucket}.s3.${this._region}.amazonaws.com`;
// ...
Location: `${endpoint}/${params.Key}`

The default branch embeds the bucket in the hostname, so it is correct. The custom endpoint branch uses the endpoint verbatim and never accounts for the bucket, which for a bare regional or self-hosted endpoint means the bucket is simply missing.

This affects the DigitalOcean Spaces configuration documented in the README, which sets s3overrides.endpoint to a bare regional endpoint, and any S3-compatible host used the same way, for example MinIO or LocalStack.

Steps to reproduce

const s3 = new S3Adapter({
  bucket: 'mybucket',
  s3overrides: { endpoint: 'https://nyc3.digitaloceanspaces.com' },
});
const { Location } = await s3.createFile('photo.jpg', data, 'image/jpeg', {});

Actual Outcome

The first two are wrong, the bucket is absent. The third is right only because the endpoint already carries the bucket as a subdomain.

Expected Outcome

The location should address the object the same way the S3 client was configured to address it:

Notes

The addressing style is not guessable from the endpoint string alone, and guessing by testing whether the bucket already appears in the host or path is fragile, for instance a bucket named after a path segment that is really part of the endpoint. The adapter already receives the answer: s3overrides is merged into the S3 client options, so forcePathStyle is available and simply is not retained on the instance. Mirroring that flag is the reliable fix.

getFileLocation() has a related gap in its direct access branch, where the url is hardcoded to https://${bucket}.s3.amazonaws.com/... and considers neither the custom endpoint nor the region. It may be worth handling both in one change, though the practical impact is smaller because baseUrl is the documented way to control that url.

Identified while reworking #242. Neither #242 nor #591 touches this, so it needs its own fix.

Environment

Adapter version: master at the time of writing, current createFile implementation.

Start with the createFile() entry point and the s3overrides handling described in the issue, then compare the README's DigitalOcean endpoint example with the expected virtual-hosted and path-style URLs. Check getFileLocation() as a related entry point. Done means returned locations include the bucket correctly for custom endpoints and forcePathStyle configurations, with coverage for the reported cases.