Simplify deploy-tag push now that git 2.49 is the floor

[dannyroberts]

https://dimagi.atlassian.net/browse/SAAS-19703

• Do not merge before 2026-06-19 — six-week announcement window for the git 2.49 minimum (from Require git >= 2.49 on managed machines #6868) must elapse so any third-party operators have had time to upgrade.

Picks up @millerdev's original suggestion on #6865. Now that #6868 / SAAS-19703 has rolled out the new git 2.49 floor across managed machines, the version-compat workaround in _push_release_tag can go away.

The previous git init --bare + git fetch --depth=1 --filter=blob:none ... <sha> + git push dance is replaced by git clone --bare --filter=blob:none --depth=1 --revision=<sha> + push. --revision was added in git 2.49.

This is a code-clarity change, not a perf one. Bytes-on-the-wire, on-disk size, and network round-trip count are unchanged (both versions already used --filter=blob:none --depth=1); wall time is within noise — see comment thread for numbers.

Environments Affected

None.

[dannyroberts]

Local performance testing from Claude Code (I didn't validate it in great detail, but the approach it took seemed generally correct.)

  ┌──────────────────────┬───────────────────────┬──────────────────────────┬─────────────┐
  │        Metric        │ Before (init + fetch) │ After (clone --revision) │      Δ      │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Wall time (avg)      │ 0.61s                 │ 0.68s                    │ +12% slower │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Bare repo size       │ 528 KB                │ 528 KB                   │ unchanged   │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Network round-trips  │ 1                     │ 1                        │ unchanged   │
  ├──────────────────────┼───────────────────────┼──────────────────────────┼─────────────┤
  │ Subprocesses spawned │ 2                     │ 1                        │ −1          │
  └──────────────────────┴───────────────────────┴──────────────────────────┴─────────────┘

@millerdev it looks like the cleaner-looking command is actually a tad slower, like ~70 ms—so basically the same speed, but not faster. (I guess git clone --bare does a bit more default setup or something than git init --bare does.) So the benefit is entirely readability / fewer lines of code as opposed to actually being more efficient. Still happy to keep this—but I wanted to check with you and see whether you still thought it was worth it.

[millerdev]

I'm not sure I believe the profiling results. It's possible that result was realistic for a very small sample size, but would expect them to be far closer (possibly ~the same) on a more reasonable sample size. Otherwise, I'd like to know what's taking more time.

I had hoped this would be a nice code simplification (the primary win) and slightly more readable (line wrapping seems to have wiped that out). In any case, I am not strongly attached to this change. Feel free to do with it what you want.