func new ignores NoCompatibleInstall and scaffolds anyway

## Problem

The `func new` bundle gate blocks two of the three "no usable bundle" outcomes and lets the third through.

```csharp
case ExtensionBundleResolution.WorkloadMissing:
case ExtensionBundleResolution.EmptyIntersection:
// error, exit 1

default:
return 0; // NoCompatibleInstall lands here
```

`NoCompatibleInstall` means bundle workloads are installed but none satisfies the project's range. That is exactly the condition this gate exists to catch, so `func new` happily scaffolds a function that cannot run.

The malformed-range case matters too. When `host.json` has a bad version range, the resolver returns `NoCompatibleInstall` and logs "failing closed". `func new` reopens it.

## Where the code lives

Today on `vnext` this is `NewCommandRunner.EnforceBundleGatesAsync` in `src/Func/Templates/NewCommandRunner.cs`.

If #5448 merges first, the same switch moves verbatim to `NewCommandBundleValidator.ValidateAsync` in `src/Func/Templates/NewCommandBundleValidator.cs`. That refactor is behavior neutral, so this bug exists either way, just in a different file.

## Repro

Node project, `host.json` requires `[9.0.0, 10.0.0)`, only `4.35.0-dev` installed.

```
$ func new -t HttpTrigger-JavaScript -n BundleProbe
✓ Created function 'HttpTrigger-JavaScript'.
src/functions/BundleProbe.js
exit 0

$ func start
Error: No installed bundle workload satisfies
'Microsoft.Azure.Functions.ExtensionBundle' [9.0.0, 10.0.0).
Installed versions: 4.35.0-dev.
exit 1
```

Same project, same host.json, opposite verdicts. You get a green checkmark and a file on disk, then hit a wall when you try to run it.

## Expected

`func new` fails the same way `func start` does, and surfaces the `Hint` the variant already carries. That hint already names the installed versions and the exact install command.

## Fix

- add `NoCompatibleInstall` to the failing cases
- render its `Hint` instead of the generic "none is resolvable" text
- make `default` fail closed like `ValidateExtensionBundleInitializationStep` does, so a future variant cannot slip through silently

## Notes

`func start` already handles all four variants and throws on unknown ones, so the two consumers of the same resolver disagree today.

func-new.spec.md §4.8.2 lists only `WorkloadMissing` and `EmptyIntersection` in its failure row, but that row describes the category as "no bundle resolvable at all", which covers this variant. The spec table probably predates the variant being split out and should get the same update.

Found while reviewing #5448.