feat(telemetry): track inline-completion and inline-chat acceptance separately

[pjdoland]

Summary

Adds telemetry so the two AI code-entry surfaces, auto-complete (inline completion) and cell inline chat, are tracked as distinct features with their own event identifiers. Three new TelemetryEventType values are introduced: inline-completion-accepted, inline-chat-accepted, and inline-chat-dismissed. This lets a TelemetryListener measure how often inline completions are accepted versus ignored, and how often inline-chat generations are applied versus dismissed, with auto-complete and inline chat cleanly separable.

Solution

For inline completion, JupyterLab's provider interface has no accept callback, so the reliable accept signal is the inline completer widget's accept() method. Rather than subclass InlineCompleter (which would force us to reproduce JupyterLab's factory wiring: translator, toolbar buttons, keybinding hints), we wrap JupyterLab's own IInlineCompleterFactory, let it build the fully wired widget, and patch only accept() on the instance. The wrapper installs on app.started, which resolves after every plugin has activated (so JupyterLab's default factory is already set and ours wins as the last writer) but before layout restoration creates the per-editor completer handlers, which capture the factory once at creation and are never regenerated. IInlineCompleterFactory is taken as an optional dependency, so NBI still loads if JupyterLab ever stops providing it.
For inline chat, inline-chat-accepted fires when generated code is applied (with a review vs auto-insert mode discriminator), and inline-chat-dismissed fires when the popover is torn down after code was shown but never applied. An interrupted stream surfaces a marker but no usable code, so its teardown is treated as a failure rather than a dismissal.
Design note: we track acceptance reliably and derive the auto-complete ignore rate in analysis as shown (inline-completion-response) minus inline-completion-accepted, rather than emitting an explicit ignore event. An explicit-ignore heuristic would depend on JupyterLab-internal rejection signals that are fragile across versions, whereas accept-plus-derive needs only events we emit ourselves.

Testing

src/inline-completer-telemetry.ts is covered by a focused unit test (delegation to the wrapped factory, provider-gated emit, read-before-delegate ordering, lazy model-info read). Full suite green: jlpm tsc --noEmit, jlpm lint:check, jlpm jest (376 passing), and pytest (1235 passing). Verified live in a running JupyterLab against a real model: inline-completion-accepted fires on Tab-accept with the completer toolbar UI preserved; inline-chat-accepted fires for both auto-insert and review-accept; inline-chat-dismissed fires on review-cancel and is correctly suppressed when code was applied. The inline-chat flag logic lives in the plugin command closure and is exercised by the live checks rather than unit tests.

Risks / follow-ups

Frontend (tokens.ts) and backend (api.py) enums are kept in parity by hand; no consumer switches on the type, so adding values is backward compatible. Follow-ups noted during review, all pre-existing and out of scope here: inline-chat telemetry reports NBIAPI.config.chatModel even in Claude Code mode (every inline-chat event already does this, so it should be fixed holistically); the review/auto-insert mode value could become a typed union alongside the existing editorType/chatMode string discriminators.