agentHost: map legacy `chat.tools.eligibleForAutoApproval` to managed settings (#333264)

agentHost: map legacy chat.tools.eligibleForAutoApproval to managed settings

Add a temporary compatibility mapping for the legacy VS Code setting
`chat.tools.eligibleForAutoApproval` (enterprise policy
`ChatToolsEligibleForAutoApproval`) to the Copilot SDK managed-settings
bridge, gated behind the existing false-by-default
`chat.agentHost.copilot.mapLegacySettingsToManagedSettings`.

The setting is per-tool, but the SDK managed rule grammar has no
tool-name family (ManagedRuleFamily is only Shell | Read | Write |
Domain, and an unknown family rejects the entire managed document), so a
faithful per-tool `ask` rule cannot be emitted and would silently miss
runTask, runTests, and every MCP/extension tool. A policy that marks any
tool ineligible therefore maps onto the family-agnostic bypass lock
`{ disableBypassPermissionsMode: 'disable' }`, which is deliberately
coarser and errs more restrictive: it turns off blanket escalation and
auto-approval session-wide. A policy that leaves every tool eligible
(all `true`, or empty) expresses no restriction and contributes nothing;
a malformed member fails closed toward the lock. Only enterprise
`policyValue` drives it — never user/application/workspace.

- Declare ELIGIBLE_FOR_AUTO_APPROVAL_SETTING_ID in agentHostSchema.ts so
  the platform-layer bridge avoids importing ChatConfiguration from
  workbench.
- Register the mapping via managedPermissionsSetting(..., 'policyOnly',
  ...) and document the exception in the module header.
- Leave the workbench consumers untouched so in-workbench chat keeps its
  per-tool behavior.
- Cover the resolver (eligible/ineligible/empty/removed/malformed,
  non-policy layers, un-duplicated co-existence with
  chat.tools.global.autoApprove) and add Agent Host lifecycle coverage
  that this setting's policy value is forwarded on connect and cleared
  before the next turn.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>