Editor hint: service registered as concrete type but implements an interface

[PaulNonatomic]

Summary

Adds a runtime/editor counterpart to analyzer rule SK006. In the ServiceKit window, a service that is registered under its concrete type but implements a user-defined interface — one that is not itself registered in the locator — now shows a small amber i badge. The tooltip suggests registering it as the interface with [Service(typeof(IFoo))].

This surfaces, at a glance, the common traps:

• A forgotten [Service(typeof(IFoo))] (service registered as its concrete type, consumers expect the interface).
• [Service] placed on an abstract base class, where it has no effect because the attribute is declared Inherited = false — exactly the V1→V2 migration trap.

Behaviour / false-positive guards

• Interface-keyed registrations never trigger it (serviceType.IsInterface → no badge).
• If the interface is registered elsewhere in the same locator (intentional dual registration), it's excluded — no badge.
• Only user-defined interfaces are considered; System.*, UnityEngine.*, UnityEditor.*, Unity.*, Cysharp.*, Mono.*, Microsoft.* are filtered out.
• Only the most-derived interfaces are listed (a base that another listed interface extends is dropped).

Files

• Editor/ServiceKitWindow/ServiceItem.cs — hint computation + amber badge (inline-styled, class hook service-interface-hint for future theming).
• CHANGELOG.md — Unreleased entry.

Validation

Self-reviewed; not yet compiled in Unity (no Unity available in this environment). Needs an editor compile + a quick visual check that the badge renders and the tooltip reads correctly. Happy to run an EditMode batchmode compile if you close Unity, as before.