Add Common/RestClientBase to the package exports map

[Dmitry Zhukovsky (dzhukovsky)]

Problem

Since v5, the package ships an exports map (generated in buildpackage.js). The map lists the root entry and one entry per API area (./Build, ./Git, ...), and — as exports maps do — restricts subpath resolution to the listed entries only.

This broke the deep import that extensions with custom REST clients rely on:

import { RestClientBase } from "azure-devops-extension-api/Common/RestClientBase";

export class MyRestClient extends RestClientBase {
    // this.beginRequest(...)
}

RestClientBase is the base class custom clients must extend (it is what getClient() constructs), but it is not re-exported by Common/index.ts nor by the package root — the deep path was the only way to reach it, and it worked in every version before the exports map existed. With v5, bundler-mode TypeScript fails with:

error TS2307: Cannot find module 'azure-devops-extension-api/Common/RestClientBase' or its corresponding type declarations.

and bundlers refuse to resolve the path at build time for the same reason.

Fix

Add an explicit ./Common/RestClientBase entry to the generated exports map, alongside the area entries:

"./Common/RestClientBase": {
    "import": "./esm/Common/RestClientBase.js",
    "require": "./Common/RestClientBase.js",
    "types": "./Common/RestClientBase.d.ts"
}

Both target files are already emitted by the build (bin/Common/RestClientBase.js, bin/esm/Common/RestClientBase.js), so this only exposes what is already shipped.

An explicit entry (rather than re-exporting RestClientBase from Common/index.ts) restores the exact import path existing extensions already use, avoids touching the public API surface of ./Common, and follows the file's existing no-wildcard convention. It also keeps the docs pipeline unaffected, since it walks subpath exports of API areas.