Fix relative links in user profile READMEs

What does this MR do and why?

Fix relative links in user profile READMEs — fixes Relative links don't work on user page READMEs (#596262 - closed).

We add :project and :requested_path to context in BlobViewer::Markup. This ensures the renderer has the context to resolve relative links it needs even when called by UsersController.

Most places end up supplying this accidentally-on-purpose through having set @project in their repsective controller — app/helpers/markup_helper.rb's markup helper sets context[:project] and context[:requested_path] if they're unset. It wouldn't really be correct to set @project in UsersController, but the blob viewer has the context it needs anyway, so we don't need to pretend we don't.

The last time BlobViewer::Markup#banzai_render_context was substantively changed was in BlobViewer::Markup includes commit_id as :commi... (!206664 - merged), and I've been careful here to heed its learnings: setting :ref would be a mistake per !206664 (comment 2789989426) / !206664 (0dc144c7) (see commit message). The default ref used is the project's default branch, which is the correct choice for the user profile README.

Screenshots or screen recordings

Given this repository at root/root:

With the following content for README.md:

![](tplove.png) awawa

Viewing http://gdk.test:3000/root gives:

Before	After

Note the image source in the "before" variant is just tplove.png, which resolves to http://gdk.test:3000/tplove.png since the current URL is http://gdk.test:3000/root.

How to set up and validate locally

1. Set up a user repository per the above example for a user on your GDK (probably root).
2. Go to /root and observe it doesn't load the image.
3. Check this branch out.
4. Refresh. Viola! 🎻

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.