fix(coding-agent): type ExtensionKernelTools as the shipped invoke scope surface

[code-yeongyu]

Summary

#1765 shipped kernelTools.invoke(request, { signal?, scope? }) and capabilities.invokeScope, but the coding-agent public ExtensionKernelTools declaration still had invoke(request, signal?: AbortSignal) and no capabilities. Typed consumers had to cast.

Coding-agent now owns the shipped surface (ExtensionKernelTools, KernelToolInvokeOptions, KernelToolInvokeScope). senpi-codemode imports those types from @code-yeongyu/senpi and binds with satisfies ExtensionKernelTools / KERNEL_TOOLS_CAPABILITIES satisfies ExtensionKernelTools["capabilities"], so the implementation cannot drift from the declaration. A bare AbortSignal remains typed. Runtime behavior is unchanged.

The reverse import (coding-agent → senpi-codemode) is not used: senpi-codemode already depends on coding-agent, and the other direction is a workspace build cycle.

Test plan

• RED: compile-only fixture asserting ctx.kernelTools.invoke(req, { scope: { tools: { deny: ["write"] } } }) and ctx.kernelTools.capabilities.invokeScope failed tsc --noEmit (scope is not on AbortSignal; capabilities is missing).
• GREEN: the same fixture type-checks after the coding-agent-owned types (tsc --noEmit exit 0). bun run build completes workspace package entries without the previous @code-yeongyu/senpi cycle.

Refs #1731

[code-yeongyu]

Reversed the type ownership after the first CI run: coding-agent importing @code-yeongyu/senpi-codemode created a workspace cycle (senpi-codemode already depends on @code-yeongyu/senpi), so tsgo -p tsconfig.build.json failed with TS2307: Cannot find module '@code-yeongyu/senpi'.

Coding-agent now declares ExtensionKernelTools / KernelToolInvokeOptions / KernelToolInvokeScope. senpi-codemode aliases those types and satisfies the host capability so drift fails its typecheck instead.