deno

729eaaee - fix(install): identify generated tsconfig by sentinel, not path string

fix(install): identify generated tsconfig by sentinel, not path string The resolver-side coupling between the generated .deno/tsconfig.json and Deno's checker leaned on two fragile string matches: - `.contains(".deno/tsconfig.json")` on extends targets — wouldn't fire on Windows (where the path uses backslashes) and would also drop a user-written file legitimately at that path. - Stripping the literal string "deno" from `compilerOptions.types` — invisibly clobbered the rare user who genuinely wrote that. Tag the generated tsconfig with a top-level `_deno_generated: true` sentinel (stock tsc/tsgo ignore unknown top-level properties). The read path now exposes that bit, and the extends filter skips by the flag rather than by path. The types-filter for "deno" was now dead (generated tsconfigs no longer make it past the extends filter) so remove it.