Is it worth to forecast the story points per sprint and add the same in the contract

If Product Backlogs are already defined and well structured, why bother to Sprint at all? Without any apparent need for empiricism or validated learning, what purpose would a Sprint contractually serve?

Have to agree with @Ian.  There doesn't seem to be a need for Sprints if there is no reason to inspect and adapt as you work.  At this point, it seems like you would be better off doing some form of waterfall.  Put together a contract that says you will deliver exactly what the customer has asked for now at some point in the future that you feel is enough time to deliver it.  

Then after you deliver that result in X months, it might be a good experiment to see how closely the delivery is to what the customer actually needs at that time and decide if you used the correct approach.  Maybe then, you could learn enough to start understanding the benefits of Sprints so that in the future you can deliver what the customer needs at the time it is delivered instead of deliver what the customer needed X months ago. 

And I wouldn't be me if I didn't touch on the story point thing.   Story points are meaningless in this context. Especially in this context. Why bother estimating your work?  If the contract reads that there will be 28 story points delivered in every Sprint, there is a very high probability that your team will estimate 28 story points every Sprint.