Your proposal is very interesting and well written! I believe that making random numbers easily accessible for DApp developers will be incredibly beneficial, and I like the idea of providing different pathways with varying levels of strength for developers to choose from.
As a reusable infrastructure project, it seems like a perfect fit for the grant program. I’ll refrain from commenting on the budget, I think it’s best left to the community to assess
About the project itself:
Regarding the Simple PRNG, have you considered incorporating something less predictable than just the block.number? While this wouldn’t necessarily prevent miners from manipulating the result, it would make it more difficult for users (who own the sender address) to predict it.
One possible solution could be to include information such as block.timestamp to it. “Clock” (contained in the Cartesi Machine), “Sender address” (defined by the sender), “Block number” (somewhat predictable, but not defined by the sender), and “Block timestamp” (decided by the proposer, but more volatile) might be a good combo. This could even function as a weak VDF of sorts, cause it may take some time to collect all the necessary information haha.
This is the list of constants available to the smart contract which could be used as a seed:
https://docs.soliditylang.org/en/v0.8.17/units-and-global-variables.html#block-and-transaction-properties
Have you considered how this seed would be included in the InputBox? One approach could be to create a different “addInputWithRandomSeed” endpoint and require the DApp to only accept inputs with it, so that each time the DApp advances its state, a new random number would be available. Or, maybe you can use the Input Metadata, so you don’t even need a different endpoint, and all the inputs contain it.
Lastly, I wasn’t entirely clear on whether you were creating both the input creation outside the Cartesi Machine and the generation of the actual random number inside a TypeScript package that can be imported inside the Cartesi Machine. The first piece would be great because it could be used by other contributors to create libraries in different languages, so we’d extend this convenience to even more developers 
About the proposal:
I’d like to see a bigger list of deliverables for each milestone, so that they can be treated as self-contained. Take a look at this RFP, for instance, it might serve as inspiration for deliverables:
For instance, in the first milestone: will you deliver a npm package that can be used in Cartesi DApp to generate the random numbers? Will you create an example DApp that uses that funcionality so we can see it running/working? Will you deliver unit tests and a README? etc.
You mention some of that in the goals of the project, but I’d also add that specifically in the deliverables for the milestones.
The budget request is a bit hard to judge without understanding the exact deliverables
Thank you for submitting this proposal. The diagrams were a nice touch!