test(core): cover the two behaviours this PR changed but left unpinned

R1-17 (adapted) — the `#9827` test sweep removed the only guard that
`Config.initialize()` tolerates non-string entries in a settings array.
The path that guard protected is gone with `isLsToolEnabled`'s revert, so
it is re-pointed at the equivalent new surface: settings load performs no
element-type validation, so `tools.eager` holding `null` or a number must
be filtered rather than crash registry construction.

R1-18 — `isLsToolEnabled()`'s reverted behaviour had no test. The eight
deleted tests only covered the positive allowlist path that no longer
exists; nothing pinned the negative. Added a test asserting that
`permissions.allow` / `permissions.ask` coverage no longer opts
`list_directory` into registration, so only `tools.listDirectory.enabled`
or `coreTools` can open that gate.

The docs findings from the same review (R1-1/R1-2/R1-4/R1-5/R1-12) are
already fixed by e3e2fcebd1 on this branch, which also covers the
specifier-rule and MCP deny-exemption nuances; nothing further is needed
there.

Deliberately not addressed: R1-15/R1-16 concern an integration-test file
this revision does not touch. R1-19 (scheduler if/else ordering) and R1-22
(`removePersistentRule` coverage) are pre-existing gaps in files #10080
also edits, so adding tests there now maximises the conflict between the
two PRs for marginal gain — better done once both have landed.

packages/core/src/config/config.test.ts

@@ -8425,6 +8425,28 @@ describe('Server Config (config.ts)', () => {
       },
     );
 
+    it('does not register list_directory just because a permission rule covers it (#10075)', async () => {
+      // Pins the reverted #9829 side effect: `permissions.allow` / `ask`
+      // used to opt this tool in at registration. They are pure
+      // auto-approval now, so the opt-in gate must stay closed and only
+      // `tools.listDirectory.enabled` or `coreTools` can open it.
+      const config = new Config({
+        ...baseParams,
+        coreTools: undefined,
+        permissions: { allow: ['ListFiles'], ask: ['ListFiles'] },
+      });
+      await config.initialize();
+
+      const registerToolMock = (
+        (await vi.importMock('../tools/tool-registry')) as {
+          ToolRegistry: { prototype: { registerFactory: Mock } };
+        }
+      ).ToolRegistry.prototype.registerFactory;
+      expect(
+        (registerToolMock as Mock).mock.calls.map((call) => call[0]),
+      ).not.toContain(ToolNames.LS);
+    });
+
     it('should ignore coreTools overrides in bare mode', async () => {
       const config = new Config({
         ...baseParams,

packages/core/src/permissions/permission-manager.test.ts

@@ -2823,6 +2823,25 @@ describe('PermissionManager', () => {
       );
     });
 
+    it('tolerates non-string entries instead of crashing initialize()', async () => {
+      // Settings load performs no element-type validation (the schema
+      // declares only `type: 'array'`), so a stray number/null must be
+      // skipped rather than crash registry construction.
+      pm = new PermissionManager(
+        makeConfig({
+          eagerTools: [null, 42, 'ReadFile'] as unknown as string[],
+        }),
+      );
+      expect(() => pm.initialize()).not.toThrow();
+      expect(pm.isEagerToolAllowListActive()).toBe(true);
+      expect(await pm.getToolRegistrationStatus('read_file')).toBe(
+        'registered',
+      );
+      expect(await pm.getToolRegistrationStatus('send_message')).toBe(
+        'deferred',
+      );
+    });
+
     it('malformed entries drop out but still leave the list active', async () => {
       // Deferring more than intended is recoverable (ToolSearch still
       // reaches every tool); silently ignoring a configured list would