FuzzyScorer ships in MeshWeaver.Data but declares namespace MeshWeaver.AI.Completion #2344

What

src/MeshWeaver.Data/Completion/FuzzyScorer.cs — a file in the core data project — declares:

namespace MeshWeaver.AI.Completion;   // line 3

public class FuzzyScorer

The assembly is MeshWeaver.Data. The namespace says MeshWeaver.AI. Those are different things and here they disagree.

Worse, MeshWeaver.AI.Completion is a split namespace: the other three types in it (AutocompleteClient, AutocompleteStreamProvider, SkillAutocompleteProvider) really do live in src/MeshWeaver.AI/Completion/. So one namespace spans two assemblies, and only one of them is AI.

Who consumes it — all core

Why it matters beyond tidiness

It makes "has MeshWeaver.AI left core?" unanswerable by search. #2276 is removing the AI assembly from core; after that lands, core production source will still contain the literal string MeshWeaver.AI — in a namespace declaration and in a fully-qualified new inside core hosting. A reader, or a grep-based audit, sees MeshWeaver.AI.Completion in MeshWeaver.Hosting and concludes core still depends on AI. It does not — but nothing about the name says so.

It also cost real time today: I removed using MeshWeaver.AI.Completion; from a core test believing it was a leftover AI import, and the build failed on FuzzyScorer — a type that never left core.

The inverse error is the expensive one: someone deleting an AI-named namespace as part of the extraction, and taking a live core type with it.

Fix

Rename the namespace to match the assembly — MeshWeaver.Data.Completion, which is what the file's own directory already says. Then update the four consumers, including the fully-qualified construction in StaticNodeQueryProvider.

Small and mechanical; the only care needed is that MeshWeaver.AI.Completion must keep existing for the three types that genuinely belong to it.

Found while clearing MeshWeaver.Content.Test for #2276.