That problem is common to all shared-library approaches, which are
found in Java, .NET, Rails and many other environments. Even in
Delphi, you will be relying on a number of external libraries, such as
most of the Windows .dlls, so it's not such a big step from what you
have been doing so far.
Normally, when you move an applicaiton into production, you want to
deploy it with a known set of libraries. With Rails, you can freeze
the current rails version you are using for development (rake
rails:freeze:gems), which copies all rails libraries into the vendor
folder of the application.
If a change to a library breaks compatibility, there is usually a very
good reason for the change (e.g. a security fix). A comprehensive
suite of automated tests helps detect these kinds of breakages.
In practice, I have very very rarely seen this happen. Libraries are
almost always more stable (in terms of versions) than your application
and will generally have a longer shelf-life as well.
You definitely don't want to think about "sealing" ruby libraries. By
the very nature of Ruby, there is a lot of code out there that
achieves amazing things by redefining or extending existing classes or
methods (e.g. the Enumerable mixin or the various acts_as_* plugins
Depending on how you deploy your app, you can either choose a hosting
environment that gives you control over the installed gems or - if you
are deploying a stand-alone application - you can have a look at the
various packaging methods (RubyScript2Exe and friends), which package
up the required libraries into a single file.
In summary, I really wouldn't lose any sleep over it. I don't think it
is as big an issue as you'd expect.