Generated flows lose finished work: the publish git push runs under the 30s default step timeout #135

Software Garden run ccbc27c8 on AgentWorkforce/flows (for flows#605, on the #132 source) ran 1h46m, then died with no PR:

lease_exceeded: f.run step "run-26" exceeded its command timeout … step exceeded its 30000 ms timeout

run-24 (prepare change metadata, 8ms) and run-25 (validate metadata, 2.4s) passed; run-26 is the next step, await f.run("base=" + baseCommit + "; " + pushBranch + " --set-upstream origin HEAD"). That step, and the other pushes (comment=yes; pushBranch after a fix round), the openChange, dropWorkingFiles and the draft/report steps, run with no timeout, so they get the kernel's 30s default. A push of a branch to a large repository (flows) takes longer, the push is killed, and because a timed-out f.run throws, the whole run fails: the work is never pushed, which is exactly the loss #132's time plan was meant to prevent.

Ask (web/lib/flow-workflows.ts):

• Give every network step in the publish path an explicit timeout: pushes and openChange e.g. "5m"; the draft/comment/report steps "2m"; dropWorkingFiles (rewrites commits) "5m". Account for them in FLOW_TIME.publishMinutes (10 today) and say so in the comment.
• A generator test asserting no f.run containing git push, openChange/relayflow-open-change, relayflow-change or gh pr is emitted without a timeout.
• Then existing Gardens need the new source again (flows deploy <file> --flow <name>; the Relayfile group via the group edit).

Related: cloud#4108, #132, #134.