TL;DR: I'm begging for help to get code written that will create an option for allowing, in the screen-off state, a long-press of the power button to toggle the flashlight on or off. I realise just because the code gets written doesn't mean it gets merged. I can't program my way out of a paper bag: I intend to pay someone to write it for me, and my post here is to ask if any kind souls might help me write the tasking that would get put out to tender, so to speak.

History of task:

Flashlight toggle upon long-press power button has come up on the forum numerous times. The best response I thought was from @Carlos-Anso who wrote:

For years there have been repeated requests to add this button press flashlight shortcut to GrapheneOS. So many that the team now almost considers it a meme.

The response is always the same. As GrapheneOS is focused on security and privacy any use of physical button press shortcuts would be for a privacy or security features.

There is a long list of work the team plans to implement which has higher priority than adding button press shortcuts.

Devs have very patiently explained that they will not develop this feature (at least here, here, and here).
- To my mean understanding, the most useful reply was that the feature is not available in the stock pixel OS.
Under Settings > System > Gestures > Press and hold the power button, there is a nascent setting that appears to have no user-settable features.
- In the AOSP code base, "press and hold power button" either opens the power menu, or opens the Assistant feature. My (mean bordering on knuckle-dragging) understanding is that this is where the feature would need to appear.
- I'm conscious that the thing that probably causes so many to pester devs with repeated requests for the described feature is that LineageOS has made it available to users. The LineageOS' code for the feature is here, and the way they've had it working for the last _8yrs has worked (for me, at least) superbly.

My thoughts:

I am here as a grateful user of GrapheneOS having migrated following the end of DivestOS. The work of the devs in creating GrapheneOS is truly awe-inspiring, and gives me hope for a brighter future.
I've started getting tendonitis in odd places, and manipulating my telephone while carrying things in my other hand is painful; being able to put my free hand in my pocket and - without reference to the screen - pull out a flashlight, was a really fantastic asset to me whilst using my previous telephone.
- I currently use the corner function pinning on the lock screen to switch on the flashlight, however manipulating the telephone with one hand to see the screen is sometimes problematic. I share my personal motivation for this post because it is important to me that the depth of my gratitude for GrapheneOS' existence remains clear throughout.
I share @matchboxbananasynergy and others' dim view of giving accessibility permissions to a third party app in order to achieve the goal.
This post was posted in 'off-topic' because I don't want to trouble the devs with this until I have a useful solution I can present for their consideration. Frankly I think specialists should be protected from the brainless gabbling of the general public (and in this case, I am the general public). I'm fully aware that the devs may not have capacity to review the code perhaps even for many years. It is not, realistically, within my gift to change that, however I can at least explore ways I might get some of the work begun.
My impression is that it would be easier for the devs to accept this feature if it were available in the AOSP. I presume one has to have many grey beards to get code accepted into the AOSP, but if anyone knows the best course of action to achieve this, I'd be all ears.

My ask:

Would it be more productive if I were to strive to get this written so that it could be submitted for consideration for the AOSP, rather than for GrapheneOS?
Would it be more productive if I asked someone to write a script that would fork GrapheneOS and inject the required code? (I'm not wholly sure how updates would work for such a fork; my impression is that this course of action is less productive, but I would gladly be corrected).
If my proposed course of action is likely to be the most productive means to my end, then: are there any technically inclined forum users who might be willing to work with me to formulate the question that ought to be asked of a programmer to achieve the goal of getting the feature developed to the stage it could be submitted for consideration?
Perhaps the most important 'ask', as whenever the general population speak to specialists, they often not only have the wrong end of the stick, but are barking up completely the wrong tree: Should I be asking a different question altogether? And if so, what?

In closing:

I must reiterate my love for this project, my gratitude to the developers, and my wish to pursue this in a way that doesn't get up anyone's nose. I realise that there is a world of difference between programming a feature, and having the programming accepted into the product, and that the latter might very well never happen in this case (hence my posting in off-topic). Being a thicko, I may have got the words wrong making this meme, but I hope it will go some way to conveying my understanding that even the richest features may have to wait for many decades to get into production: