Two lint rules enforce the generated-types contract with non-overlapping scopes and no cross-reference

Two lint rules now enforce the same policy family, in two engines, with non-overlapping scopes and no cross-reference.

| | `comfy/no-new-zod-for-remote-api-types` | `comfy/no-duplicate-ingest-type` |
|---|---|---|
| Landed | #14951 | #14839 |
| Engine | ESLint, flat-config `no-restricted-syntax` | oxlint JS plugin |
| Scope | `src/platform/remote/**`, tests ignored | everywhere oxlint runs, by import provenance |
| Catches | new hand-written Zod for remote API types | a type imported from `@comfyorg/ingest-types` and re-declared locally |

Both exist because hand-written copies of a server contract drift from it. Neither mentions the other, in its own message or in `docs/guidance/typescript.md`.

## Why it matters

The gap between them is real, not theoretical. `WorkspaceIdentitySchema` in `workspaceAuthStore.ts` was a hand-written `z.enum` mirroring a generated union: a widened role would have failed `safeParse` and silently cleared session storage on load. It sits in `src/platform/workspace/`, so the Zod rule does not see it, and it is a schema rather than a type declaration, so the ingest rule does not either. It was caught by review, not by tooling, and fixed in #14839 by picking off `zWorkspaceWithRole`.

`docs/guidance/typescript.md` now says to prefer the generated Zod schemas over hand-written ones when validating a response, so the guidance reaches past the glob. Nothing enforces it outside `src/platform/remote/**`.

## Worth deciding

- Should the Zod rule widen beyond `src/platform/remote/**` now that generated schemas are available at `@comfyorg/ingest-types/zod` and in use in several places?
- Should the two rules cross-reference each other in their diagnostics, so hitting one tells you the other exists?
- Is one engine the long-term home? The ingest rule cannot be expressed as `no-restricted-syntax` (it correlates an import alias map with a later declaration, which a single-node esquery selector cannot do), so the split may be permanent. If so, `docs/guidance/typescript.md` should say which rule covers what rather than leaving it to be discovered.

Filed as a follow-up to #14839; not blocking anything.

Start by reading `docs/guidance/typescript.md` and comparing the two named lint rules and their scopes; the issue does not name their source files. The open questions need a decision on scope, diagnostics, and engine ownership before there is a concrete change to implement; done would require that decision and any resulting rule or guidance changes.

Written by the indexing model from the issue text.