`quarto render` to a named pipe hangs

I think what's happening is that we're assuming these are actual files, and Deno.readTextFileSync() hangs (I can't even ctrl-c my way out of the deno process.) If I rm the named pipe, then the next ctrl-c yields an error deep inside the html postprocessors:

NotFound: No such file or directory (os error 2), open 'a-pipe'
    at Object.opSync (deno:core/01_core.js:174:12)
    at openSync (deno:runtime/js/40_files.js:39:22)
    at readFileSync (deno:runtime/js/40_read_file.js:11:18)
    at Object.readTextFileSync (deno:runtime/js/40_read_file.js:39:24)
    at runHtmlPostprocessors (file:///Users/cscheid/repos/github/quarto-dev/quarto-cli/src/command/render/render.ts:1038:28)
    at renderPandoc (file:///Users/cscheid/repos/github/quarto-dev/quarto-cli/src/command/render/render.ts:657:39)
    at async Object.onRender (file:///Users/cscheid/repos/github/quarto-dev/quarto-cli/src/command/render/render.ts:860:26)
    at async renderFiles (file:///Users/cscheid/repos/github/quarto-dev/quarto-cli/src/command/render/render.ts:310:9)
    at async render (file:///Users/cscheid/repos/github/quarto-dev/quarto-cli/src/command/render/render-shared.ts:96:18)
    at async Command.fn (file:///Users/cscheid/repos/github/quarto-dev/quarto-cli/src/command/render/cmd.ts:179:26)

it seems hard to handle this correctly in general, so we should probably refuse to render to an existing location if we're in a unix system and we detect that a named pipe exists there.

Start in src/command/render/render.ts, especially runHtmlPostprocessors and the renderPandoc call shown in the stack trace. Reproduce rendering to an existing Unix named pipe and inspect how Deno.readTextFileSync() is reached. Done means the CLI refuses this destination instead of hanging, with the behavior limited to the stated Unix named-pipe case.