Name the rerun controls after what they rerun

[skipi]

What

The two rerun controls on the workflow page describe themselves in ways that invert their actual scope. The header button reads Rerun but starts a completely new workflow from the same commit. The button on a failed pipeline row reads Rebuild Pipeline but is the narrow one — it re-runs only what did not pass inside that single pipeline. Reading the labels, "Rebuild Pipeline" is the one that sounds like a full restart, so people reach for whichever button is nearest and get the scope they did not want. That is the confusion reported in #686.

This renames both controls after what they rerun and makes the difference legible without a click:

• Header: Rerun → Rerun Workflow, tooltip "Starts a fresh run of the whole workflow from this commit". Same on the job page header, where the tooltip also keeps the "including this job" note.
• Pipeline row: Rebuild Pipeline → Rerun Failed Jobs, tooltip "Reruns only the jobs in this pipeline that did not pass, keeping the ones that did. Use Rerun Workflow above for a fresh run of everything."

That row tooltip previously existed as a plain title attribute and did not surface in the tree. It now uses data-tippy-content, the mechanism the rest of the app uses: app.js binds those on page load, and Pollman already destroys and rebinds tooltips around each partial refresh, so the tooltip survives the tree's polling. Button sizes are unchanged — the row keeps btn-tiny, matching Stop Pipeline next to it.

Follow-through so the rename does not leave stale copy behind: the tree JS in-flight label (Rebuilding... → Rerunning...) and its error-restore label, the workflow editor's rerun-granularity section (which named the button in its explanatory line), and the docs passage describing both buttons — that passage additionally claimed the header button "restarts the whole pipeline from the beginning", which is wrong; it restarts the workflow.

Routes, permissions, feature gating and behaviour are untouched. The row button still renders only behind ui_partial_ppl_rebuild, so organizations without that feature see a single unambiguous Rerun Workflow.

Scope

This is a deliberate low-effort interim step: it fixes the vocabulary, not the layout. The larger piece of work — collapsing both controls into one pipeline-scoped Rerun menu that enumerates the pipelines with failures — is being explored separately (#1178 carries the playground it is designed in). The vocabulary picked here is the vocabulary that design lands on, so this rename is not thrown away when the menu ships.

Verification

Copy-only change; no spec asserts any of the renamed strings. The guest-path assertion in workflow_controller_test.exs that refutes the presence of a rerun button is unaffected — anonymous and guest viewers render workflow/_workflow.html.eex, which has no rerun control at all. Relying on CI for compile, format, lint and the front suites.

Left for a follow-up

docs/docs/using-semaphore/pipelines.md embeds img/rerun-pipeline.jpg, a screenshot showing the old labels. It needs to be retaken once this is deployed. The versioned CE/EE docs are intentionally not touched — released versions still ship the old labels.

Stop Pipeline, in the same row, still has no tooltip at all.