packaging: the WinGet sentences say only what was measured, and the command line is now measured too

An outside review of #144 said two sentences claimed more than was measured:
the command line's upgrade warning was inferred from the window, and the README
presented an issue with one reproduction as true of every package.

The command line is now measured. On Windows 11 in user scope, with a tfg run
held in progress, the upgrade failed with "Access is denied" and left only the
program and the notices in the folder, and ran through once the run ended - the
same as the window. The window measurement was repeated there with the same
result, so the description now says what happens rather than a general rule.

The PATH entry left after an uninstall was reproduced in user scope on Windows
11 as well as in machine scope on Windows Server 2025, for both packages, with
WinGet 1.29.380. The README says that, and describes microsoft/winget-cli#6160
as a report of the same for another package.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: donislawdev

.github/scripts/build_packages.py

@@ -85,21 +85,24 @@
 def how_to_start(package, feed):
     """The paragraph that differs by feed: what the package gives and how to start it.
 
-    The WinGet sentences about upgrading are measured, not assumed: on Windows
-    Server 2025 with WinGet 1.29.380 on 2026-09-25, upgrading the window while
-    it was open failed with "Access is denied" and left the package folder half
-    removed until the upgrade ran again with the window closed. A portable
-    package can carry no script to warn at that moment, so the description is
-    the only place a person can read it first.
+    The WinGet sentences about upgrading are measured, not assumed, with WinGet
+    1.29.380 on 2026-09-25: on Windows Server 2025 in machine scope and on
+    Windows 11 in user scope, upgrading the window while it was open failed
+    with "Access is denied" and left the package folder half removed until the
+    upgrade ran again with the window closed. On Windows 11 the command line
+    did the same while a tfg run was in progress. A portable package can carry
+    no script to warn at that moment, so the description is the only place a
+    person can read it first.
     """
     other = next(p for p in PACKAGES if p is not package)
     other_id = other.winget_id if feed == "winget" else other.choco_id
     if package.kind == "cli":
         text = ("This package is the command line, for scripts and pipelines. The desktop "
                 "window is the package %s. Type tfg help to see the commands." % other_id)
         if feed == "winget":
-            text += (" Upgrade it when no tfg run is in progress. WinGet cannot replace a "
-                     "program while it runs.")
+            text += (" Upgrade it when no tfg run is in progress. WinGet cannot replace "
+                     "tfg while it runs, so it stops half way, and the package works again "
+                     "once the upgrade runs with no run in progress.")
         return text
     if feed == "winget":
         return ("This package is the desktop window. The command line is the package %s. "

packaging/README.md

@@ -36,10 +36,12 @@ the real file. With it, WinGet makes no link and puts the package's folder on
 depends on the machine - a link where symbolic links are allowed, the folder on
 `PATH` where they are not. WinGet adds no Start menu shortcut for a portable
 package, and the window's description says so. One cost of the field is not
-ours to fix: WinGet leaves the package's folder on `PATH` after an uninstall -
+ours to fix. WinGet 1.29.380 left the package's folder on `PATH` after an
+uninstall, for both of these packages, in machine scope on Windows Server 2025
+and in user scope on Windows 11 - measured on 2026-09-25, the entry stays and
+points at a folder that no longer exists.
 [microsoft/winget-cli#6160](https://github.com/microsoft/winget-cli/issues/6160),
-open, and true of every package that sets it. Measured here with WinGet
-1.29.380: the entry stays, pointing at a folder that no longer exists.
+open, reports the same for another package that sets the field.
 
 **Chocolatey.** The package downloads the release archive rather than carrying
 it, so it holds no binaries and owes no `VERIFICATION.txt`, and the archive is the
@@ -56,8 +58,9 @@ and an icon on a branch would keep changing under an approved package.
 
 **Neither package ends a running program** - a run in progress may be halfway
 through a set of files, and cutting it would leave files with no manifest to say
-what they are. What each feed does instead was measured on Windows Server 2025
-on 2026-09-25, with the window open:
+what they are. What each feed does instead was measured on 2026-09-25, with the
+program running - Chocolatey on Windows Server 2025, WinGet there in machine
+scope and on Windows 11 in user scope:
 
 - **Chocolatey goes ahead**, an upgrade and an uninstall alike, and reports
   success. It moves the package folder aside to `lib-bkp`, and the running copy
@@ -67,8 +70,9 @@ on 2026-09-25, with the window open:
   names the folder to delete once the program is closed.
 - **WinGet stops half way.** An upgrade fails with "Access is denied" on the
   program, having already deleted some of the other files, and the package works
-  again once the upgrade runs with the window closed. A portable package carries
-  no script, so the description is where this is said.
+  again once the upgrade runs with the program closed. Measured for the window
+  and, on Windows 11, for the command line with a run in progress. A portable
+  package carries no script, so the description is where this is said.
 
 ## Submitting