multi-node builder should not fallback to detected platform if node with manual platform errors

Description

Repro steps:

1. Create a driver with this spec:

{"Name":"remote","Driver":"remote","Nodes":[{"Name":"remote0","Endpoint":"tcp://localhost:1234","Platforms":[{"architecture":"arm64","os":"linux"}],"Flags":null,"DriverOpts":null,"Files":null}

2. Send a request to the builder for a different platform

docker buildx build -t out --platform linux/amd64 .

Expected result:

I would expect to fail because there's no available builder that matches the platform

Actual result:

buildx sends the request to the ARM builder

Additional info:

The full problem is more complicated, and involves how the Node fallback logic works when one of the builders is unavailable. Basically we're seeing problems where if platform isn't specified, and one of the builders is unavailable, the request ends up landing on a random Node and with a random Platform.

I think it would be fine if this behavior was opt-in, i.e., there was a driver opt like:

{"Name":"remote","DriverOpts":{"DefaultPlatform": "linux/amd64", "StrictPlatformMatching": true}}

Reproduce the issue with the remote driver specification and the docker buildx build --platform linux/amd64 command, then trace the multi-node Node fallback logic when a builder is unavailable. Done means an explicitly requested platform does not fall back to a node with a conflicting manual platform, and the unavailable-node behavior is covered.