R: fix capture "saving" hang via CameraConductor remote-release path

[jed2nd]

What

On the EOS R, ML's programmatic capture (lens_take_picture → call("Release"))
takes the picture but leaves the shooting job unfinalized, so the camera hangs on
"saving..." at power-off. The physical shutter is unaffected.

This drives the CameraConductor remote-release event (SetEventIrRemoteReleaseBtn)
instead — the same path a wireless remote / the physical shutter uses — which
finalizes the job cleanly. 1 = press (SW2-on), 0 = release.

Changes

• platform/R.180/stubs.S — add SetEventIrRemoteReleaseBtn (0xE0190214)
• src/dryos.h — prototype, guarded by CONFIG_R
• src/lens.c — #elif defined(CONFIG_R) branch in lens_take_picture

This mirrors the existing per-camera release variants already in that function
(PtpDps_remote_release_SW1_SW2_worker for 5D2, rssRelease for 5DC,
FA_Release for 40D).

Testing (EOS R, firmware 1.8.0, on hardware)

• Capture through the standard take_a_pic path now takes a photo and powers off
  cleanly — no "saving" hang.
• The breadcrumb trail completes through job_state set (exposure started); the
  proper CC path also sets job_state, which call("Release") did not.
• Capture uses AF_DONT_CHANGE (MF / pre-focused). ML-driven AF on the R is a
  separate matter (CONFIG_IMAGE_CAPTURE_NOT_WORKING) and out of scope here.

Notes

SetEventIrRemoteReleaseBtn posts the remote-release event into the normal
CameraConductor SW1/SW2 pipeline (RE'd from ROM0). Builds clean for R.180.

[jed2nd]

Verified on EOS R (firmware 1.8.0) hardware after this fix — sharing the results in
case they're useful, since they show what the fix unblocks.

Capture (this PR):

• Standard take_a_pic / lens_take_picture now captures and powers off cleanly — no
  "saving…" hang.
• AF capture: with the lens in AF, an easy subject focuses + captures cleanly; a hard
  subject where AF can't lock fails gracefully (job_state timeout → clean return),
  no crash. So the CONFIG_IMAGE_CAPTURE_NOT_WORKING concern ("crashes if it fails to AF
  lock") no longer reproduces via this path.

Quick stability pass:

• LiveView + Global Draw / Cropmarks overlay: stable.
• Survives the camera's power-save sleep → half-shutter wakes both the Canon and ML UIs
  cleanly.
• ~10 min mixed + idle use, no crashes; modules (bench, file_man) load fine.

Downstream (intentionally not in this PR): with capture working, I enabled
FEATURE_INTERVALOMETER locally to sanity-check — left out of this PR since it's a
features.h policy change that's yours to decide. It works: a 10 s interval produced 4
well-formed full-size frames and stopped / powered off cleanly.

Happy to share logs or more detail. (SetEventIrRemoteReleaseBtn address RE'd from ROM0.)

[kitor]

Interesting, I tested multiple ways to trigger the shot but all of them were leaving it in that broken state - and all of them were related to factory mode.

I don't recall SetEventIrRemoteReleaseBtn so if that works it is a very good catch. I hope to test that in near future on multiple cameras (starting with R of course) and then we will probably merge this and enable intervalometer.

[jed2nd]

I've yet to have success with this for HDR/Bracketing, but it does work for intervalometer for sure. Continuing to dig.

[reticulatedpines]

We could log the state machine during capture, which may give additional clues. We didn't have a clean good capture to work with before, so couldn't do a nice comparison.

This is fairly hard code to work on (you need to do some hand-coded asm), but not crazy hard.

For a fairly clean example of how to install logging hooks, see e.g. https://github.com/reticulatedpines/magiclantern_simplified/tree/b9d9a9557bb4f1345e342c55b5bb998263f98853/modules/dev_tools/adtglog2

If you're interested in that, consider joining us on Discord, we can give much more rapid advice there :)