Investigate the inherited Nuke.* IDE add-on internals grants

Reminder to investigate — not scheduled.

## Problem

`AssemblyInfo.cs:22-28` still grants `InternalsVisibleTo` to five out-of-repo assemblies inherited from NUKE, all on the old namespace:

```
Nuke.VisualStudio, ReSharper.Nuke, ReSharper.Nuke.Rider,
Nuke.Remote.Functions, Nuke.Website.Functions
```

Two things bother me about this:

1. **They're an unverifiable coupling.** FT-2 ([#451](https://github.com/Fallout-build/Fallout/pull/451)) made `BuildManager.CancellationHandler` a silent no-op outside an active run. Anything in that list subscribing before `Execute` now loses its handler quietly. Nothing in this repo can confirm whether that matters — the code lives elsewhere. Every future de-statification step (FT-4/5/6) has the same blind spot.
2. **The namespace is wrong.** These grants privilege `Nuke.*` internals access indefinitely, which cuts against the rebrand being otherwise done.

## Outcome

Know what's actually on the other end of those grants, then decide: drop them, or replace them with first-party add-ons built clean.

## Look into

- [ ] Are any of the five still maintained / still consuming Fallout internals? Which internals?
- [ ] Anything actually broken by the FT-2 no-op, or by the FT-1/FT-2 teardown?
- [ ] Which grants can just be deleted.
- [ ] First-party add-ons: ReSharper/Rider and Visual Studio, alongside the VS Code extension already underway (milestone #22). Built fresh on `Fallout.*` — not ported.
- [ ] If we own the add-ons, does the internals surface need to be public/`[Experimental]` API instead of `InternalsVisibleTo`?

Related: [#545](https://github.com/Fallout-build/Fallout/issues/545), [#546](https://github.com/Fallout-build/Fallout/issues/546) (the untested seams that make #1 hard to reason about).