test(objectql): the discovery provider assertion follows the scoped package name (#4093 follow-up)

`protocol-discovery.test.ts` pinned `services.auth.provider` to the bare label
`plugin-auth`. It now comes from CORE_SERVICE_PROVIDER, which names the package
you can actually install — the FROM → TO the changeset already declares for
this field.

Scoped is the point, not incidental: `provider` is what a consumer (or an
agent) reads to decide what to fetch, and `@objectstack/plugin-auth` is
copy-pasteable into an install command where `plugin-auth` is a guess at best
and, for the ten slots this PR corrected, wrong outright.

Caught by Test Core, not by my filtered local runs — a `provider`/`message`
assertion can live in any package that exercises a discovery builder, and this
one is in objectql.

Deliberately NOT touched: the `provider: 'plugin-search'` and `Install
plugin-workflow to enable` strings in spec's discovery/dispatcher schema tests.
Those are arbitrary payloads proving ServiceInfoSchema accepts a shape, not
claims the platform makes — and "fixing" them means inventing a slot→package
pairing for slots that have none, which is the very thing this PR removes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UNGqBQcdJ2RYHtWgntJ9B

Author: claude

packages/objectql/src/protocol-discovery.test.ts

@@ -41,7 +41,9 @@ describe('ObjectStackProtocolImplementation - Dynamic Service Discovery', () =>
     expect(discovery.services.auth.enabled).toBe(true);
     expect(discovery.services.auth.status).toBe('available');
     expect(discovery.services.auth.route).toBe('/api/v1/auth');
-    expect(discovery.services.auth.provider).toBe('plugin-auth');
+    // [#4093 follow-up] Scoped now: `provider` comes from CORE_SERVICE_PROVIDER,
+    // which names the package you can actually install rather than a bare label.
+    expect(discovery.services.auth.provider).toBe('@objectstack/plugin-auth');
     expect(discovery.routes.auth).toBe('/api/v1/auth');
   });