Hokay. It looks very as though there's no Netscape support for client-side XSLT processing right now. I'd love to be proven wrong, but I can find no evidence for the existence of such hooks, based on the web searching I've done. Whereas Microsoft was all too happy to show me three different ways of writing my content to XML but having it rendered (via XSL) to HTML client-side. Draw what conclusions you wish.
In any event, I've gotten my hands on James Clark's freeware Java implementation of XSLT. My first idea, which I dismissed as overly complicated, was to rebuild my pages to generate CGI queries that would call into XT, parametrized by which one of my pages was being requested, and serve up the resulting HTML. I've since had the better (or worse, depending on perspective) idea that I can just use XT on my own computer every day or so to regenerate HTML versions of all my pages and then upload them to the server. I don't like this way of doing things, since XML+XSL+CSS is fundamentally a client-side technology whose whole point is to make web content generation entirely declarative, and precompilation steps intrinsically worry me. But such drastic measures may be necessary, as least until the W3C manages to force XLink down people's throats properly.
I'll stop geeking now, I promise.