add uvr bootstrapping like renv when

[B-Nilson]

when opening an R session in a project with renv enabled, but renv not installed, there is some code run (started by the .Rprofile, calls the renv/activate.R script) that bootstraps the install of renv.

For uvr, we could have it install the uvr-r package if not installed, then use that to install the uvr CLI.

Here is what it looks for renv in a project where I updated R so don't have any packages installed for that version yet (including renv):

 $ R

R version 4.6.0 (2026-04-24) -- "Because it was There"
Copyright (C) 2026 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

# Bootstrapping renv 1.1.5 ---------------------------------------------------
- Downloading renv ... OK
- Installing renv  ... OK

[nbafrank]

@B-Nilson — yes, this is the right pattern; renv's activate.R is the model. Wanted to think through the design call before coding because there are a few branches I'd want your call on:

Where the bootstrap lives. Two options:

1. Inline in the uvr-managed .Rprofile block — extend the existing snippet to detect missing `uvr-r` and install via `remotes::install_github("nbafrank/uvr-r")` or `pak::pkg_install("nbafrank/uvr-r")`.
2. Separate `uvr/activate.R` that the .Rprofile sources — closer to renv's structure, keeps the bootstrap logic out of the user's .Rprofile so they can read/audit it as a separate file.

I lean (2) — easier to update, easier to audit, more familiar to renv users. Tradeoff: one extra file in every uvr project (renv ships 3+ files in `renv/` so the precedent is fine).

When to bootstrap.

• First run (uvr-r not installed): yes — install + load
• Every subsequent run: no — if uvr-r is already installed, just `requireNamespace("uvr")`
• After a failed bootstrap: don't retry on every session startup (would slow R startup if user is offline). Mark a sentinel file `.uvr/.bootstrap-failed` and skip on subsequent runs until the user explicitly re-runs `uvr::install_uvr()` or deletes the sentinel.

Bootstrapping the CLI binary too?
You mentioned "then use that to install the uvr CLI." renv stops at installing renv. We could either:

• Stop at uvr-r (user runs `uvr::install_uvr()` themselves) — explicit, safer
• Auto-cascade: uvr-r's onLoad downloads the CLI binary — magical, slower-on-first-load

I lean explicit. The CLI binary is multi-MB, downloads from GitHub releases, and silently fetching it on R startup feels surprising.

Install method.
Try `pak` first (faster + better diagnostics), fall back to `remotes`, finally fall back to `install.packages("remotes"); remotes::install_github(...)`. Same fallback chain as the existing `update_uvr()`.

If you're good with (2) + sentinel-on-fail + explicit CLI install + pak/remotes/install.packages fallback, I'll implement it. Otherwise nudge me on which knob you'd flip.