Print time to complete estimates

[hunterhacker]

We now estimate time to complete in gauging if the max read/write rate is high enough to fit within the timeout. Maybe we should print that to the console? For something like delete with two phases it should print each phase appropriately.

I don't know how accurate the timings will be. It's one thing to use extrapolated timings to WARN on things that will obviously take more than the timeout. It's another thing to make good estimates.

[hunterhacker]

Spike attempted and parked — not merging it

Tried a first cut at this and it isn't good enough to ship. Recording what was built and why it fell short so the next attempt doesn't repeat it.

Preserved on branch spike/286-time-estimate-ramp-model (single commit, cbc97de). Deliberately no PR — it's a reference, not a merge candidate.

What it did

Replaced the flat total_units / rate duration estimate with one shaped like a real Glue run:

~2 min Glue startup
+ ~30 s worker deploy
+ a ramp: first three minutes at 1/4, 1/2, 3/4 of target rate (90 × rate units)
+ full rate thereafter

and printed a user-facing line: Estimated <dimension> time to complete: ~N min.

The startup/ramp shape is a real improvement over a flat divide, and it matches what a Glue run actually looks like for small and medium tables.

Why it isn't mergeable

It still assumes the target rate is the eventual sustained rate. That's the load-bearing assumption, and it's wrong precisely where an estimate matters most — very large tables, which in practice never reach the requested rate. Fixing the startup shape while leaving that assumption in place trades a simple wrong answer for a complicated wrong answer, which is worse: the output looks more authoritative without being more accurate.

Secondary: no tests. _estimated_completion_seconds is pure and self-contained so it would be cheap to cover, but that work wasn't done because the model wasn't worth investing in yet.

What a better attempt probably needs

The sustained rate has to come from observation, not the request. Some options:

• Sample actual throughput over the first N seconds of the data-movement phase and extrapolate from that, rather than from --XMaxWriteRate.
• Use the observed-vs-requested ratio from a prior phase for multi-phase commands (delete = scan then write) — that ratio is already implicitly available.
• Emit a range rather than a point estimate, so the output doesn't over-claim.

The ramp/startup constants from the spike are reusable in any of those.

One design question worth settling before rebuilding

Is a wrong-but-confident estimate better or worse than no estimate? The existing timeout warning (_warn_if_job_may_timeout) already tells users when a rate can't finish in the remaining budget, which covers the actually-dangerous case. A "time to complete" line is nicer to have but carries a real risk of being trusted. Worth deciding what accuracy bar it has to clear before it earns a place in the output.