jsconsumer: serve the server ladder by not disposing; fix schedule blind spots

Review of #14 found the retry path never served the ladder it documented.

A consumer's BackOff governs acknowledgement TIMEOUTS. A plain Nak asks for immediate redelivery and the ladder is never consulted, so Settle's retry branch burned MaxDeliver in milliseconds and reached the DLQ at once — the opposite of the bounded ~20m envelope the docs and the SLA arithmetic claim. Measured against a live server with a 3s/3s/3s ladder:

So the retry path now disposes of NOTHING and lets AckWait expire. Doing nothing is what defers to the one ladder; NakWithDelay would schedule correctly but only by naming a delay this process would have to know, which is the second schedule ENT-1535 is about. The cost is that a failing delivery stays ack-pending for its rung, so MaxAckPending has to be sized for it — inherent to a server-side ladder, now stated in the docs.

Every other test here drives a FakeMsg and can only assert which disposition method was called, which says nothing about what the server does next. That is exactly how this got through, so the fix comes with an integration test that publishes to a real broker and asserts the redelivery GAPS.

Also from the same review:

• Schedule's RecoverBy and largest-rung checks read the client ladder fields directly, which are zero for a server-side ladder. Both silently saw 0 and passed configurations they exist to reject — in the only mode the library ships. Every timing check now goes through RungBefore/CumulativeTo/ LongestRung, which handle either ladder and the server's repeat-last-rung rule in one place.
• Config.BackOff is required, not optional, whenever Retry is set: Start always writes it, so leaving it nil ERASES the durable's ladder rather than deferring to whatever set it. The docs claimed a CR-managed consumer could omit it; it cannot until a bind-only mode exists that skips consumer creation. Corrected rather than papered over.

Refs ENT-1601, ENT-1535.