docsy(v2): document the two narrative gaps left by four API regens

Closes the narrative half of the accumulated api-surface-delta backlog:
docs#1262, #1373, #1424 (DOC-1362) and #1457 (DOC-1447). Four regens, two
gaps.

Enumerating them was most of the work, because the version churn hides the
signal: #1457 alone is 309 files, of which 307 of the 366 added lines are
`version:` frontmatter bumps. Stripping those leaves very little, and most of
what remains was already covered.

## flyte get devbox (new in 2.6.2, DOC-1447)

Verified new rather than reworded: present at released tag v2.6.2
(cli/_get.py:864-895), zero occurrences at v2.6.1. The devbox page taught
start, stop and delete but had no way to answer "did it come up?", which is
the question a reader has at exactly that point in the page. Added as its own
section between starting and configuring, with --no-probes and the
`-of json-raw` form.

## Fetching a report after the run (DOC-1362)

reports.md covered writing a report from inside a task and said nothing about
reading one afterwards. That is a different reader task -- pull a finished
report into a notebook or a CI job -- and it was uncovered.

Documents Run.get_report(), the attempt argument, and the .aio variant. Also
covers the root-action distinction, which is the part most likely to bite:
Run.get_report() returns the ROOT action's report, so a run whose tasks call
other tasks needs Action.get_report() for a nested one. The SDK's own docstring
was amended to redirect readers there, which is the signal that flagged this
delta as material in the first place.

All three signatures verified against v2.6.2 rather than inferred:
Run.get(name), Action.get(run_name=, name=), Run.get_report(attempt=) with a
real .aio attribute.

## What was already covered, recorded so it is not redone

- Artifacts (#1373/#1424's headline delta, 7 new reference pages): shipped
  yesterday as the user-guide artifacts section, docs#1454.
- Default pool/queue deletability (#1457): queues.md already documents the new
  semantics including the run.default_queue guard.
- TaskTemplate and DeployedAppEnvironment (#1262): already referenced in
  how-task-deployment-works.md and how-app-deployment-works.md.
- AsyncFunctionTaskTemplate (#1262): deliberately not documented. Its own
  docstring says it is "automatically created when an asynchronous function is
  decorated with the task decorator" -- users never write it, so zero narrative
  mentions is correct, not a gap.

Co-Authored-By: docsy <docsy@union.ai>
Signed-off-by: Peeter Piegaze <1153481+ppiegaze@users.noreply.github.com>

Author: ppiegaze

content/user-guide/get-started/run-modes/running-devbox.md

@@ -84,6 +84,28 @@ This pulls the necessary containers and starts a local Flyte instance. Once read
 The first start may take a few minutes while Docker images are downloaded.
 {{< /note >}}
 
+## Check the devbox status
+
+To see whether the devbox is up, and where it is:
+
+```bash
+flyte get devbox
+```
+
+This reports the run state, the UI and image registry endpoints, the container image version in use, and where the cluster keeps its state on disk. It is the quickest way to tell a devbox that is still starting from one that is ready.
+
+Add `--no-probes` to skip the readiness probe and the container resource sample, which makes the check faster and works offline:
+
+```bash
+flyte get devbox --no-probes
+```
+
+For a machine-readable report, pass an output format to the top-level command:
+
+```bash
+flyte -of json-raw get devbox
+```
+
 ## Configure
 
 Create a config file that points to the devbox:

content/user-guide/tasks/task-programming/reports.md

@@ -187,3 +187,40 @@ if __name__ == "__main__":
 > The report contains only what you explicitly `log()` or `replace()`. Returning a value whose type has a renderer attached does **not** by itself add it to the report — render the value and log the HTML, as shown above.
 
 Flyte's SDK also implements a few renderers of this kind internally — for pandas and PyArrow DataFrames and for Markdown strings. These aren't exposed as public API (only the `flyte.types.Renderable` protocol is), so treat them as examples of the same pattern rather than importable helpers.
+
+## Fetching a report after the run
+
+Everything above is about *writing* a report from inside a task. To *read* a finished report from outside the run, for example to embed it in a notebook or attach it to a CI job, fetch it through the remote API:
+
+```python
+import flyte
+from flyte.remote import Run
+
+flyte.init_from_config()
+
+run = Run.get("my-run-name")
+html = run.get_report()
+```
+
+`get_report()` returns the report as an HTML string. It requests a signed download link for the report artifact and downloads the contents, so the call needs an initialized client.
+
+By default it returns the report for the latest attempt. Pass `attempt` to fetch an earlier one:
+
+```python
+html = run.get_report(attempt=1)
+```
+
+`Run.get_report()` returns the report of the run's **root action**. A run whose tasks call other tasks has a report per action, so to fetch the report for a nested action, use `flyte.remote.Action.get_report()` on that action instead:
+
+```python
+from flyte.remote import Action
+
+action = Action.get(run_name="my-run-name", name="my-subtask")
+html = action.get_report()
+```
+
+Both are synchronous by default. From async code, call the `.aio` variant:
+
+```python
+html = await run.get_report.aio()
+```