apps: pass max_past_jobs to channel constructors

[gimballock]

Companion to stratum-mining/stratum#2307, which adds max_past_jobs: Option<usize> to the server and client ExtendedChannel/StandardChannel constructors. None and Some(0) both select the crate default MAX_PAST_JOBS, so nothing changes for callers that pass neither.

Four commits:

1. apps: pass max_past_jobs to channel constructors — pure plumbing. Every one of the 10 call sites passes None, so behaviour is unchanged. 2 in pool, 3 in jd-client, 5 in translator (one a test helper). Group channels are untouched — they take no such parameter.
2. TMP: point stratum-core at ... — temporarily repoints the stratum-core dependency at the companion branch so CI can build, following Pool+JDC: handle new SeenSharesBudgetExhausted error variant from channels_sv2 share validation #733. Must be reverted once #2307 merges and the pin is bumped to the merged rev.
3. pool: make the past-jobs cap settable from config — adds max_past_jobs to the pool config, so two otherwise-identical deployments can differ by exactly one value.
4. apps: expose max_past_jobs on tProxy and JDC too — the same setting in the other two roles, for symmetry (see the discussion below).

Each role keeps its own local config idiom: pool and jd-client via a private field plus getter, translator via a public field. Every shipped config example documents the setting commented out, so the library default stays in force unless an operator opts in, and each role has a test asserting exactly that.

Each role also logs the cap actually in force at startup. When unset it comes from channels_sv2, so it otherwise appears nowhere in the application's own config and is not recoverable from a running process.

Why expose it at all

The cap is a retention window — cap / template rate — and the template rate is a deployment property the library cannot see. The same constant buys 50 s of late-share tolerance at a 1 s template cadence and over 16 minutes at 20 s.

Sizing it also depends on what sits downstream, which differs per role: a pool faces proxies or miners, a translator faces real SV1 firmware, a JDC faces a miner or another proxy. Each sees a different submission-latency distribution, so one value chosen for one role is not automatically right for another.

[plebhash]

I'm confused with the approaches taken by Pool vs tProxy/JDC

why does only Pool get the optional config parameter?

[gimballock]

I'm confused with the approaches taken by Pool vs tProxy/JDC

why does only Pool get the optional config parameter?

oversight, I was running the test off of the pool and focusing on that. fixed now