Mangled generated path on `ln_s` with `relative: true`

I found this accidently when trying to wrote a dotfile linker utility.

Seems like FileUtils.ln_s will fail when the resulting relative path contains ../ (one directory hierarchy higher) as the relative path being generated is mangled.

Sample snippets to reproduce:

FileUtils.ln_s(
  "/home/mipan/.dotfiles/zsh", "/home/mipan/.config/zsh",
   verbose: true, noop: true, relative: true
)

Output: ln -s  /home/mipan/.config/zsh/zsh

And this is not a pure logging bug, when the noop set to false:

FileUtils.ln_s(
  "/home/mipan/.dotfiles/zsh", "/home/mipan/.config/zsh",
   verbose: true, noop: false, relative: true
)

ln -s  /home/mipan/.config/zsh/zsh
/usr/lib/ruby/3.4.0/fileutils.rb:760:in 'File.symlink': No such file or directory @ rb_file_s_symlink - (, /home/mipan/.config/zsh/zsh) (Errno::ENOENT)
	from /usr/lib/ruby/3.4.0/fileutils.rb:760:in 'block in FileUtils.ln_sr'
	from /usr/lib/ruby/3.4.0/fileutils.rb:765:in 'FileUtils.ln_sr'
	from /usr/lib/ruby/3.4.0/fileutils.rb:709:in 'FileUtils.ln_s'
	from ./dot_linker.rb:362:in '<main>'

Sample for working parameters:

FileUtils.ln_s(
  "/home/mipan/.dotfiles/zsh", "/home/mipan/zsh",
   verbose: true, noop: true, relative: true
)

Output: ln -s .dotfiles/zsh /home/mipan/zsh

Ruby version:

❯ ruby --version
ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux]

Start with fileutils.rb around lines 709 and 760, where the stack trace shows FileUtils.ln_s and FileUtils.ln_sr handling the relative link. Reproduce the failing and working snippets with relative: true, checking both noop modes. Done means the higher-directory case produces the correct relative target in verbose output and creates the symlink successfully.