Remove the 60-second limit on blocking waits

@etraut-openai

Please remove this guidance from the developer prompt for GPT-5.6:

Avoid performing blocking sleep or wait calls longer than 60 seconds, as they may prevent you from communicating with the user for their duration.

This turns every long-running command into a pointless polling loop. Chromium builds can take tens of minutes or hours, forcing the agent to make dozens of tool calls that report nothing beyond “still running." which is a waste of tokens and "burns time" (from the model's POV, it doesn't like making repeated tool calls due to "time limits").

It also harms subagent work. Repeated wait timeouts make parent agents impatient, leading to messages like “Send your concise final message now” while the subagent is still busy. This leads to suboptimal, rushed answers and the same aforementioned "burning time".

The wait tool supports up to an hour max duration. So why handicap the model in the developer prompt? In reality the model hardly sends messages to the commentary every sixty seconds when not waiting for long-running commands, so this guidance is genuinely just theater.

Furthermore because of this, the model will disregard instructions from the user to supply a higher wait as it has to comply with the higher-priority developer instructions.

There is an internal inconsistency between this and earlier guidance:

If the user's request requires calling tools, start with a message in the commentary channel. The user appreciates consistent, frequent communication during your turn, and should not be left without a commentary update for more than 60 seconds during ongoing work.

The key words are "ongoing work". A build is not ongoing work. Waiting for a subagent to finish a complex, time-consuming implementation or investigation is not ongoing work for the main thread. When the agent is totally blocked by a long-running task, it should diligently wait.

This is overall terrible universal guidance. Please remove it.

Also I'm not only considering myself here. This is generally bad advice for the model regardless of which type of user is using Codex. Please don't be uncharitable and assume I'm only fitting this to my use cases, because I'm not.

Ideally I'd reverse the guidance and say avoid tight polling if you do not need interim progress, and maybe even send a message to the commentary channel before an expensive operation informing the user it will take time. An alternative is also removing the line altogether, which is also an acceptable solution.