Resolve the master `clickhouse-examples` binary under its workflow prefix

`Parser memory check` errored in its `Resolve master binary` step on every pull
request from 2026-09-02 10:14:18Z with `No master binary found in 100 tracked
commits`. `main` returns early there, so the check produced no signal at all, and
because the job sets no `allow_failure` the error counted toward `Mergeable Check`.
The last green run started 10:30:22Z; 49 erroring runs across 48 distinct pull
requests followed by 13:03:42Z.

`get_merge_base_profiler_url` hand-spelled the artifact key as
`REFs/master/<sha>/build_arm_release/clickhouse-examples`. Praktika uploads job
artifacts to `<env.get_s3_prefix()>/<normalized job name>`, and
`_Environment.get_s3_prefix_static` now appends the normalized workflow name
unconditionally after `_should_include_workflow_name_in_s3_prefix` was deleted in
#110081 (merged 2026-08-31T08:54:37Z). That helper returned
`not workflow_name.startswith(("pr", "main", "master"))`, so it suppressed the
segment for exactly the flows this job reads, which is why the hand-spelled key was
correct before and is a permanent miss now. The artifact lives at
`REFs/master/<sha>/masterci/build_arm_release/clickhouse-examples`, which is also
the link `Build (arm_release)` records for itself in that workflow's own
`result_masterci.json` report.

The break arrived about two days after that merge because the loop returns the first
sha in `master_track_commits_sha` that resolves, and `store_data.py` fills that key
with 100 first-parent commits of the master parent of the merge commit praktika
builds. That window currently spans 1.99 days, so it had to slide entirely past the
cutover before the loop could exhaust. It is also why every open pull request broke
at one instant rather than one at a time, and why a legacy fallback would rescue
nothing.

Asking praktika for the prefix removes the duplicated layout knowledge that caused
this, so a later move follows automatically and a signature change fails loudly
instead of returning 403 for 100 shas.

Validated by calling the real function against the live 100-sha window with
`master_track_commits_sha` stubbed: before the change it printed the reported message
and returned an empty string, with the old key resolving for 0 of 100 shas; after it
resolves at depth 7, with the new key resolving for 54 of 100. A master sha whose
build has not published yet resolves on neither key, so the probe still
discriminates.

Reported by @ bacek at
https://github.com/ClickHouse/ClickHouse/pull/116552#issuecomment-5508709751
Failing job: https://github.com/ClickHouse/ClickHouse/actions/runs/33612463648/job/100219799384
CI report: https://s3.amazonaws.com/clickhouse-test-reports/praktika.html?PR=116552&sha=d5fa6652f262ce060c04c2206ec141660a43d597&name_0=PR&name_1=Parser%20memory%20check
Pull request: https://github.com/ClickHouse/ClickHouse/pull/116552

Related: https://github.com/ClickHouse/ClickHouse/pull/110081

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>