stdin: drop env-var tip from no-data warning (cubic P2)

The cause-neutral wording from 8eac6fa still kept the
`set ALTIMATE_STDIN_TIMEOUT_MS=N` tip. cubic flagged that the tip
points users at timeout tuning even when the real cause is a stream
error or the dominant inherited-idle subprocess case. Drop the tip;
the env var stays documented in code/docs for the rare slow-producer
scenario.

Final wording: "altimate-code: stdin produced no data; proceeding
without it."

Author: sahrizvi

packages/opencode/src/util/stdin.ts

@@ -99,13 +99,12 @@ export async function readStdinIfAvailable(deps: ReadStdinDeps = {}): Promise<st
 
   if (result === "") {
     // An empty result can come from the timer firing (slow producer), a
-    // clean `end` with zero bytes (intentionally empty pipe), or an error
-    // event. Wording is cause-neutral; the env-var tip is still useful for
-    // the slow-producer case and harmless otherwise.
-    warn(
-      `altimate-code: stdin produced no data; proceeding without it. ` +
-        `Tip: set ${STDIN_TIMEOUT_ENV}=N (ms) higher if upstream is a slow producer.`,
-    )
+    // clean `end` with zero bytes (intentionally empty pipe), or a stream
+    // error. The previous version included a `set ${STDIN_TIMEOUT_ENV}=N`
+    // tip; cubic-dev-ai flagged it as misleading for the error and the
+    // dominant inherited-idle subprocess cases. The env var stays
+    // documented in code/docs for the rare slow-producer scenario.
+    warn(`altimate-code: stdin produced no data; proceeding without it.`)
   }
 
   return result

packages/opencode/test/util/stdin.test.ts

@@ -173,7 +173,6 @@ describe("readStdinIfAvailable", () => {
     expect(out).toBe("")
     expect(seen).toHaveLength(1)
     expect(seen[0]).toContain("stdin produced no data")
-    expect(seen[0]).toContain("ALTIMATE_STDIN_TIMEOUT_MS")
   })
 
   test("does NOT warn when isTTY (no pipe to drop in the first place)", async () => {