Ruby stack ignores .ruby-version (and the Gemfile `ruby` directive)

Our Ruby buildpack never reads any Ruby version source. It defaults to a hardcoded "3.2" and only overrides it from [build] version in .miren/app.toml. There's no detection of .ruby-version or the ruby "x.y" directive in the Gemfile, so users who bump their Ruby version the normal way see no effect and stay on 3.2.9. The Go stack already does this correctly (parses go.mod), so Ruby is just missing the equivalent wiring.

Surfaced by a user (Javier, in Discord) trying to upgrade hanami-demo to hanami 3.0, which needs Ruby >= 3.3. Three things bit him in sequence: setting .ruby-version did nothing, and then adding ruby file: ".ruby-version" to the Gemfile broke the build entirely because we don't stage that file before bundle install.

Three fixes, roughly in priority order:

1. Read the version. Add a parseRubyVersion() to RubyStack that checks .ruby-version and the Gemfile ruby directive, wired into the opts.Version → detected → default fallback. Mirror GoStack.parseGoModVersion (pkg/stackbuild/golang.go:155, used at golang.go:185-188). Detection belongs in RubyStack.Init (pkg/stackbuild/ruby.go:121); the default lives at ruby.go:216.
2. Stage .ruby-version before bundle install. bundleInstall only copies Gemfile* into the layer (pkg/stackbuild/stackbuild.go:312), so Gemfiles that do ruby file: ".ruby-version" fail with "Could not find version file .ruby-version." The full context (including .ruby-version) isn't copied until copyApp at ruby.go:239, one step too late. Add .ruby-version to the early copy.
3. Bump the stale default. "3.2" predates infra only mirroring 3.3/3.4/4.0 (infra/image-sync/images.yaml), so a bare ruby:3.2-slim may not even be synced. Bump to "3.4".

Once 1 and 2 land, an untouched repo with .ruby-version + ruby file: ".ruby-version" builds correctly with zero miren-specific config.

Workaround for now: drop the ruby file: line and set [build] version = "3.4" in .miren/app.toml.