Auto-register staged agent builds as a pushable application

Gate collect_log on a minimum agent version and bridge the agent version
store to the applications table so a staged build can actually be pushed.

update_app resolves an install source from the applications table alone; it
cannot see agentstore. A build could therefore be staged and current while no
application row existed at all, which is what the fleet was in: the agent was
unpushable. Staging is now the single source of truth - it packages the
current build and upserts the row in the same request, so the row cannot
describe a build that is no longer staged.

PARTIAL BUILD ADVISORY
This is steps 1-4 of a longer rollout and is deliberately incomplete:
  - There is no push trigger yet. The registered package is resolvable and
	verifiable, but nothing enqueues an upgrade; the "behind current build"
	indicator is still display-only.
  - The upgrade template script, its script row, and the enqueue route
	(endpoints.agentupdate) are not written.
  - Blocking constraint for the next slice: run_script executes
	powershell.exe -File <script> with NO argument channel, so a delivered
	upgrade script cannot be passed BaseUrl/CollectorKey and must either
	source them itself or run_script must be extended first.
Nothing here touches a live endpoint. Staging only changes what a future
push would contain.

Details:
  - Package members carry a fixed timestamp. zipfile stamps the current mtime
	by default, so identical input produced a different archive digest on
	every call. update_app pins a download by SHA-256, so a drifting hash
	would rewrite installersha256 out from under an endpoint mid-download and
	fail its verification.
  - All three routes that can change 'current' re-register (upload,
	adopt-legacy, rollback). Covering only upload would leave the row pinned
	to the build an operator just rolled away from, and the push would ship
	it anyway - silent drift.
  - Registration cannot fail an upload. The binary is staged and audited by
	the time it runs, so a packaging problem is reported in the response
	payload rather than raised; returning an error would tell the operator a
	successful upload was rejected.
  - The package is written to a temp name and os.replace'd, so an interrupted
	write cannot leave a truncated archive at the path the row advertises.
  - The row is isinstallable but hidden: machine-managed, and it must not
	appear in the software catalogue beside real licensed applications.
  - Added application_package_location() to the shopdb.api contract surface
	(lazy, matching collector_authorized) returning the package directory and
	URL prefix together. agentregistry reached into shopdb.core internals,
	violating the plugin import contract; sourcing both from one place also
	stops the write location and installpath from drifting apart.

collect_log is refused at enqueue below its minimum agent version, with
numeric comparison - string ordering misplaces 1.9.0.0 against 1.16.0. The
refusal is mirrored in the UI so a command slot is not spent on a call that
is guaranteed to fail.

Test isolation: create_app('testing') resolves instance_path to the real repo
instance/ directory, so agent upload tests write into the developer's actual
store. The new tests redirect both the store and package output into tmp_path
and include a guard test that fails if that isolation regresses. NOTE: the
pre-existing test_endpoints_agentupload.py still has this leak and deposits
1.5.0.0 and 1.6.3 into instance/siteagent/ on a full run - not fixed here.

Suite: 2834 passed, 11 skipped. The two failures (test_docs_publishable, and
a symlink scan needing Windows privileges) were confirmed pre-existing by
stashing this work and reproducing them.

plugins/endpoints/frontend/views/EndpointsList.vue

@@ -61,6 +61,16 @@
       </select>
     </div>
 
+    <!-- Placeholder for the staged agent rollout. Shown only to operators who
+         hold the grant it will require, so it reads as "not built yet" to the
+         people waiting on it rather than as a missing permission to everyone
+         else. This page is due a refactor; the utility lands with that work. -->
+    <div v-if="canagentupdate" class="rollout-note">
+      Bulk Agent Update utility coming soon. Until then, agents update through
+      the existing installer push, and an endpoint behind the published build is
+      flagged on its own detail page.
+    </div>
+
     <!-- Actions live here rather than per row. A tenth column of buttons
          pushed itself off the edge of a nowrap table, and selecting one row
          costs a single click while giving one command path instead of two. -->
@@ -194,6 +204,9 @@ const toast = useToast()
 // Gated in the UI for convenience only; every enqueue is re-checked server-side.
 const cancommand = computed(() => authStore.hasPermission('endpoints.command'))
 const canrestart = computed(() => authStore.hasPermission('endpoints.restart'))
+// Reserved for the staged rollout. Agent replacement is the control plane
+// modifying itself, so it stays separate from ordinary app deployment.
+const canagentupdate = computed(() => authStore.hasPermission('endpoints.agentupdate'))
 
 const allselected = computed(() =>
   endpoints.value.length > 0 && selected.value.length === endpoints.value.length)
@@ -515,6 +528,18 @@ function changePerPage(newPerPage) {
 
 .bulk-count { font-size: 0.9rem; margin-right: 0.25rem; }
 
+/* Deliberately quieter than .bulk-bar: this announces something that does not
+   exist yet, so it must not compete with controls that actually do work. */
+.rollout-note {
+  padding: 0.6rem 0.9rem;
+  margin-bottom: 0.75rem;
+  font-size: 0.9rem;
+  color: var(--text-light);
+  background: var(--bg-card);
+  border: 1px dashed var(--border);
+  border-radius: 0.25rem;
+}
+
 .select-cell { width: 1%; }