What guarantees do "soft" real-time operating systems actually provide I think I know what a "hard" real-time operating system is.  It is an operating system with a scheduler that provides a contract with the application programmer.  An application provides a deadline with each resource allocation request.  If the deadline requests are feasible, the scheduler guarantees that each resource will be allocated to the requesting application before the deadline.  The guarantee is sufficient to enable an application programmer to reason about the maximum latencies and minimum throughputs of specific requests.

All the definitions I find of "soft" real-time systems seem vacuous to me.  Wikipedia says


  the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.


Uhhhh.  Okay.  By that criteria Windows 95 was a soft real time system and so was 3BSD and so is Linux.  Wikipedia is not a great source, but the next couple of Google hits aren't much better.  For example http://users.ece.cmu.edu/~koopman/des_s99/real_time/ says


  In a soft real-time system, a degraded operation in a rarely occurring peak load can be tolerated.


That's not a contract, that's a fancy way of saying nothing.

What are examples of real soft real-time guarantees/contracts offered by real operating systems?

I'm looking for answers of the form:


  In (OS-name) if programmer does (what-programmer-needs-to-do) then the operating system guarantees (what-the-system-guarantees).
You've got it right, and Wikipedia is as informative as can be — soft real-time is not a formal characterization, it's a value judgement. Another way to say “soft real-time” is “I wish it was real-time”, or perhaps more accurately “it should be real-time but that's too hard”.
If you really want to word in the form of a guarantee, it's a guarantee of best effort rather than a guarantee of specific performance.
Or, to quote the Erlang FAQ (Erlang is a programming language originally designed for use in telephony):

What does soft realtime mean?
Cynics will say &quot;basically nothing&quot;.
(…) Many telecomms systems have less strict requirements [than hard realtime], for instance they might require a statistical guarantee along the lines of &quot;a database lookup takes less than 20ms in 97% of cases&quot;. Soft realtime systems, such as Erlang, let you make that sort of guarantee.

And this does provide a useful definition. Soft real-time indicates a design which is optimized towards each individual task taking no more than a certain amount of time, rather than towards optimizing the total time spent to perform all tasks. For example, a soft real-time system would aim to complete 99.9% of the requests in 10ms and process 100 requests per second, where a non-real-time might aim to proceed 200 requests per second but allow the occasional request to block for 50ms or more. A hard real-time would guarantee one request every 15ms no matter what.
Soft real-time is used for applications where a missed deadline means a degradation of service, but is not performance-critical. Multimedia and telephony are some typical use cases. Each audio or video frame must be rendered it time, or else it has to be skipped; but skipping a frame is not the end of the world. The designers of Erlang had similar objectives on reliability in other matters: they observed that it was better for a telephone exchange to very occasionally drop a call, but to be absolutely sure that the exchange as a whole would keep working come what may, than to ever risk catastrophic failure in trying to maintain connections at all cost.
In contrast, something like controlling a motor requires that the software never misses a deadline. This has costs: the overall performance is typically slower, and only relatively simple behaviors can be achieved. On the other side of the spectrum, a number crunching application typically cares only about overall performance — what matters is how fast the 1000x1000 matrices are multiplied, not how fast each column is calculated.