refactor(git-sync): internalize the engine — first-class ESM, no vendoring bridge (#119 review)

Closes the architecture item from the #119 review: drop the "vendored from
docmost-sync" framing and the CJS↔ESM `Function('import()')` bridge so the engine
is a normal first-class gitmost package.

Part 1 — vendoring markers removed (prose only, zero behavior change): reworded
"VENDORED into gitmost" / "vendored from docmost-sync" / "Engine LOGIC is
byte-identical" / "it's a port" comments across the engine. Behavior-bearing
strings are untouched: BOT_AUTHOR_NAME/EMAIL and the `Docmost-Sync-Source:`
provenance trailers (changing them would break git authorship + the loop-guard).

Part 2 — the package is now ESM (matching the sibling @docmost/mcp): `type: module`,
tsconfig Node16, `.js` extensions on relative imports, and a static
`import { marked }` replacing the `new Function('return import(...)')` /
`loadMarked` hack — the bridge is GONE from the package. The CommonJS NestJS
server loads the now-ESM engine via a new `git-sync.loader.ts` that mirrors the
existing `docmost-client.loader.ts` mcp loader exactly (Function-indirected
dynamic import + cached promise + retry-on-reject). The 4 server consumers
(orchestrator/datasource/vault-registry/git-http-backend) call `await loadGitSync()`
for value exports; types stay `import type` (erased). The converter-gate spec —
which needs the real converter — loads the package's TS source via a jest
moduleNameMapper + isolatedModules (documented in that spec); the other git-sync
specs mock the loader.

Verified: engine builds pure ESM (no Function/require leftover), vitest 614,
editor-ext build, server + client tsc, full server jest 1397/0. Live stand
smoke-test: server starts clean on the ESM engine (no ERR_REQUIRE_ESM), a real
sync cycle runs through the loader, and the basic e2e suite is 12/12 (clone via
git-http-backend, push, pull, delete, 3-way merge — all through the new loader).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

packages/git-sync/src/engine/settings.ts

@@ -1,16 +1,14 @@
 /**
- * Engine settings (ADAPTED for vendoring).
+ * Engine settings.
  *
- * Upstream this module also loaded `.env` (`dotenv`) and bound `parseSettings`
- * to `process.env` via a `loadSettings()` entry point. In gitmost the engine is
- * driven IN-PROCESS by the NestJS server, which builds the `Settings` object
- * from `EnvironmentService` — so the engine must NOT reach into
- * `process.env` here. We therefore vendor ONLY:
+ * The engine is driven IN-PROCESS by the NestJS server, which builds the
+ * `Settings` object from `EnvironmentService` — so this module must NOT reach
+ * into `process.env`. It exposes only:
  *   - the `Settings` type the engine consumes, and
  *   - `parseSettings(env)` as a PURE function (validate a raw env object -> typed
  *     `Settings`), kept for unit tests and for the server to reuse if it wants
  *     to validate an env-shaped object.
- * The `loadSettings()` / `loadDotenv()` side-effecting entry point is dropped.
+ * There is no `.env`-loading side-effecting entry point.
  */
 import { z } from 'zod';