Ah, JTAG. The standard that is universal as it is useless.
JTAG is a universal 'standard' primarily because it defines everything without really defining anything. Remember, it began as a way to test entire circuit boards and their integrity at large, it was never defined as (nor is it meant to be) a programming/debugging/in circuit emulation protocol, though it makes for a great physical bus to implement such features upon. One of the more handy features is that it is highly chainable, allowing you to daisy chain many devices on one board and test (or whatever) them all using just one JTAG interface.
JTAG is really just a state machine, one that gives you access to memory addresses. It does not specify any sort of protocol or system for doing anything to anything, it merely provides the medium. How or what you actually do over the JTAG interface is going to be highly specific to the chip in question, and often these functions are not published and require using vendor provided hardware and software.
A 'JTAG programming/debugging interface' isn't some standardized thing. It will utilize, in some way, the JTAG state machine, but there is no implication of interoperability or universality here. That interface is as unique and specific to the chip in question as is allowed by the JTAG standard. To use an analogy, JTAG might be standardized mail system, with addresses and formatting and maybe specific paper and envelopes that must be used, all very rigorously defined. What it doesn't define particularly well is what you actually write on those letters. It specifies the typewriter, type face, size, spacing, alphabet, etc., but what you actually write is still left mostly up to you.
OK, I took significant liberties with that analogy but I think it gets the point across.
So when that chip's datasheet says 'inputted the specified waveform', that's the nice way of telling you that they aren't going to tell you how to put the chip in programming mode. It says to consult the user guide for their flash programmer, the JET51. It's in chinese, but it certainly doesn't expose their proprietary protocol (which is clearly intellectual property worth billions, at least in one naive executive's mind anyway) so you can build your own device and software.
Unfortunately, the answers to many of your questions are for Sino Wealth to know and you to...well... not. Have you tried writing them an email? Who knows, maybe they'll let you sign an NDA or something.
Now, things could be worse. There are vendors who won't even sell you a programmer or the proprietary software needed to use it unless you're a large business and your engineers all sign NDAs, make some sort of occult blood pact etc. But fortunately, Sino Wealth knows how to chill out a little, and has graciously provided the user guide, firmware (!!) for their programmers, and the needed software. How does it work? If Sino Wealth won't tell you, I'm afraid your only option left is to reverse engineer all of that as well. Given that there are several third party programmers that support that specific chip, and that they provide the software and even firmware for their programmers, it is likely not too hard to reverse engineer. Or you can just buy a JET51 programmer. Whether you use it or reverse engineer its operation is up to you.
Also, the state machine flowchart you've screencapped is of Sino Wealth's proprietary SSP programming mode and totally irrelevant to the 'specified waveform' mentioned in the ICP flash programming section, and has nothing to do with the JTAG programming interface. It has nothing to do with the rest of your question, sadly.
As for the LCD, it doesn't matter. The SH79F1619 is a segment LCD controller. It controls segments of an LCD using 12 segment drivers, and 4 common pins for multiplexing. There is nothing special here, it is no different from driving a 7 segment LED display. Each segment makes a segment 'light' up on the LCD. Which segment that is, or what it even looks like, is left to the designer of the LCD. There is nothing special to know - you can drive the segments with any LCD segment driver chip and they will work exactly the same with any other driver as this microcontroller.
The only thing that is different between an LCD and LED is that LCDs must be driven with AC, while LEDs are obviously driven with DC. This is totally generic and usually works just like you would operate an LED, only with AC. Want a segment to be on? Apply an AC voltage. Want it off? Apply no AC voltage (or really, just a much smaller AC RMS voltage). All the LCD controller is doing for you is switching COM and the various segment pins back and forth relative to each other, and usually between a few bias voltages to create a stepped wave form and give you some nice features like variation in contrast/greyscale etc. But this is utterly generic and you don't need to know anything about this LCD. If you want to speed a weekend filled with frustration, you can even bitbang it yourself using a micro and a few transistors to switch between bias voltages. If you suffer from suicidal ideation, I advise against attempting this though.
My final concluding thoughts:
Life is short. Don't spend the most precious resource of all, time, on this. There is no reason to reverse engineer all this. It won't be a particularly valuable learning experience - you'll learn a lot about a very specific chip and its proprietary programming interface that is going to be utterly unremarkable and just another variation on the same crap done for decades in superficially different implementations by all sorts of micros. And there is nothing worth recovering and decompiling in that chip anyway. There is nothing revolutionary about a crappy flash micro with a built-in LCD segment controller and a "10-bit" (probably closer to 6 bits and another 4 of worthless noise) analog to digital converter. There is nothing to learn from that code, and you will match or better it by simply writing your own from scratch for a more open and available micro. Atmel makes chips like the atmega169 which has the same lcd segment controller pins available, a public and well documented programming interface, opensource tools, and oodles of sample code.
I do not presume to tell you if a project is worth doing or not, or interesting or not. Everyone has their own definition of fun - and I say, have at it. Make this coffee maker behave, or give it a PID control loop, or make it run linux and add a CAN bus so your car can talk to it - go nuts. But don't waste your time reverse engineering something that is not worth anyone's time to reverse engineer. If you don't care so much about the coffee maker and want to reverse engineer something, then pick something that will help you learn reverse engineering skills, not pointless specifics of some proprietary system. Or, from a different angle, pick something that actually might have something interesting and worth recovering. Though, I doubt anything worth while would just be sitting there waiting for someone to dump it.
Trust me - there are tons of equally interesting things to spend your time on, far more than can fit in any human lifespan. Pick the good ones, or the best ones of you can manage it, and forgoe the lesser ones. Even if that means never learning the 200 assembly instructions that make your coffee machine tick.
Best Answer
Assuming the processor you are referring to has boundary-scan cells behind the pins that are connected to the Flash device you want to program, you should be able to program the Flash with JTAG/boundary scan without involvement of the processor's core. There are also some other JTAG based programming methodologies that can help to speed up the programming compared to boundary-scan based Flash programming (which is relatively slow).