Enhancement: support block/unblock at pipeline level (as well as process level)

Nobody has claimed this yet.

## Possible bug

The methods `sharp.block()` and `sharp.unblock()` seem to impact all instances and of all dependencies in the tree, not just the one required/imported.

In fact, it even impacts different versions of sharp on the same machine.

### Is this a possible bug in a feature of sharp, unrelated to installation?

- [x] Running `npm install sharp` completes without error.
- [x] Running `node -e "import 'sharp'"` completes without error.

If you cannot confirm both of these, please open an [installation issue](https://github.com/lovell/sharp/issues/new?labels=installation&template=installation.md) instead.

### Are you using the latest version of sharp?

- [x] I am using the latest version of `sharp` as reported by `npm view sharp dist-tags.latest`.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of `sharp` that is not the latest, please open an issue against that package instead.

### What is the output of running `npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp`?

```
System:
OS: macOS 26.6
CPU: (11) arm64 Apple M3 Pro
Memory: 253.45 MB / 36.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.23.1 - /usr/local/bin/node
Yarn: 1.22.22 - /usr/local/bin/yarn
npm: 12.0.2 - /usr/local/bin/npm
pnpm: 11.18.0 - /usr/local/bin/pnpm
bun: 1.3.14 - /opt/homebrew/bin/bun
Deno: 2.4.1 - /opt/homebrew/bin/deno
```

### Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to `EBUSY` or `EPERM` errors on Windows.
Use [`sharp.cache(false)`](https://sharp.pixelplumbing.com/api-utility#cache) to switch this feature off.

- [x] Adding `sharp.cache(false)` does not fix this problem.

### Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

- To auto-orient pixel values use the parameter-less [`rotate()`](https://sharp.pixelplumbing.com/api-operation#rotate) operation.
- To retain EXIF Orientation use [`keepExif()`](https://sharp.pixelplumbing.com/api-output#keepexif).

- [x] Using `rotate()` or `keepExif()` does not fix this problem.

### What are the steps to reproduce?

Create two instances of sharp, and have use default and the other block. The order you run the code matters.

### What is the expected behaviour?

Should succeed regardless of the order.

### Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

```js
function optimizeSvg() {
const sharp = require('sharp')
const svg = Buffer.from('')
return sharp(svg).png().toBuffer().then(() => console.log('svg success')).catch(() => console.error('svg FAIL'))
}

function optimizeJpg() {
const sharp = require('sharp')
sharp.block({ operation: ['VipsForeignLoad'] })
sharp.unblock({ operation: ['VipsForeignLoadJpeg'] })
const jpg = Buffer.from('/9j/2wBDAP//////////////////////////////////////////////////////////////////////////////////////wAALCAABAAEBAREA/8QAJgABAAAAAAAAAAAAAAAAAAAAAxABAAAAAAAAAAAAAAAAAAAAAP/aAAgBAQAAPwBH/9k=', 'base64')
return sharp(jpg).png().toBuffer().then(() => console.log('jpg success')).catch(() => console.error('jpg FAIL'))
}

optimizeSvg() // success
.then(optimizeJpg) // success
.then(optimizeSvg) // FAIL
```

### Please provide sample image(s) that help explain this problem

Not needed since its inlined

Start by running the issue's optimizeSvg and optimizeJpg reproduction, focusing on sharp.block() and sharp.unblock() and the order-dependent pipeline behavior. Trace how these calls affect separate sharp instances and determine how pipeline-level scope should behave. Done means the sample succeeds regardless of operation order without affecting unrelated instances or versions.

Written by the indexing model from the issue text.