How should I behave as a developer in a project that's headed for failure?

Admittedly on one of those occasions, the effect wasn't immediate -- the manager in question basically rage-quit the conversation. But she put a lot more thought into getting confrontational in future disputes.

(Although I have to clarify that this was a fairly dysfunctional environment (and had been for a while), due to which I figured getting things in writing was the safest choice. In future more cohesive settings, I didn't bother with this as much, as the teams tended to have more integrity.)

This, unfortunately, seems to be a rather large factor when it comes to figuring out why a project failed. Unrealistic expectations are absolute killers.

Well, I've done it. I've developed complete solutions to business problems that the company was trying to solve. I did it without waiting for permission or for my design to be approved, and I did it only after I fully researched and understood the problem space and the future goals of the company. Then I made sure the design took into account all of those future contingencies without being rigorously bound by them, i.e. flexible and not a hindrance when the business goals change in the future -- which they always do. At the most recent company I worked for (a massive corporation) the system is expected to be in production for the next 3 years at a minimum. I did the first 90% of the work in two months, then the other 90% of the work in another month or so. The fourth month was spent primarily on training, documentation, and meetings.

Competence exists. The managers are simply given the authority to squander it or to perceive it as a threat and fire them. I was lucky enough to have a manager who was receptive to me overstepping my bounds as a contractor. I made decisions (such as making Redis a core requirement of my design) before asking permission or waiting for approval. I presented a demo of an early version of it to my manager at the end of my first week, and thankfully he was both surprised and happy about it. (40x improvements to the existing infrastructure tend to elicit that reaction.) But most large corporations, and even many small ones, aren't like that at all. You'd be fired for overstepping your boundaries, whether or not you were capable of making a difference to the bottom line. It's up to the manager, and that is a wholly backwards way of running a modern software corporation.

For software companies, there has got to be a better way than the existing approach. At the very least, the concept of a "manager" should be divided into two people: a manager and a producer. The producer's role is to drive their project's goals. The manager's role is to ensure that the employees are happy and to deal with roadblocks (such as if an employee needs to purchase a third-party tool). The manager has the authority to fire people; the producer does not. The manager's goal is to look after the team, not the project. And neither of them can tell an employee what to do. The employees are given tasks to complete, not steps to complete, and then trusted to complete that task. The employee is trusted not to accept tasks which he/she feels are too ambitious for the producer's timeline. So the producer can only barter with the employees, not demand from them.

I know of a massive videogame company (not Valve) which operates that way, and it's the reason they're currently the industry leader in their genre even though they've grown exponentially as a company over the past four years, both in employee count and customer count. So it absolutely worked for them, and I'm willing to bet that it would work in a lot of software companies. I want to prove that it works.

In "extra" time, start Plan B. Find the parts of the code that might be usable for another project (possibly this one's successor). Make sure their interfaces and dependencies make that easier - which is good software engineering anyway, and can be justified as such if you don't want to explain the real reason. That way you and your employer will both be able to extract maximum benefit from the project when it does fail, helping you both to survive the aftermath.

You will be criticized for not committing enough to the project. You might even be blamed for its failure. It's very unlikely that you'll ever get any credit for helping the phoenix rise from the ashes. That sucks, but it's a bad situation all around and you have a duty to try if that's what you think is best for the company in the long term.

(P.S. To be perfectly honest, I'd already be out of there if I felt that way about a project, but that's the sort of advice the OP was explicitly not seeking.)