Pin forgectrl 0.1.28, forgeext 0.1.0, grblHAL-glowforge 0.1.19, forgefirm-app 0.1.31 on the pushed heads, and meta-openglow in the kas lock

The extensions work, merged into each component's default branch and
pushed, is what the recipes now fetch:

- forgectrl 55bfae9 (0.1.27 -> 0.1.28): the machine lease, the job runner,
  the controller port client and motion routes, scoped tokens, the event
  stream, the built-in registry, the operator's door to extension packages
  and the Extension packages card, the catalog from its own repository,
  and privacy advisory revision 4.
- forgeext 711f099 (first pin, 0.1.0): the extension host, and ffx new
  making a package's repository.
- grblHAL-glowforge 0da0fe6 (0.1.18 -> 0.1.19): manual homing, the X and Y
  motor release, the controller port, custom M-codes, the envelope rule,
  and the homing runner's report secret.
- forgefirm-app 021323d (0.1.30 -> 0.1.31): the report secret, and a
  homing motion cut short failing the home.
- kas lock: meta-openglow 71fad52 -> 2978522, the kernel's sandbox options
  (NF_TABLES, LANDLOCK, MEMCG, the cgroup scheduler) and their notes.

Proof: bitbake -c fetch of forgectrl, forgeext, grblhal-glowforge,
python3-gfhardware, gfhome, gfcloud and python3-ffmachine from these pins
succeeds (14 tasks), with kas moving layers/meta-openglow to 2978522. The
tree manifest from these pins holds forgectrl at 55bfae9 (211 files),
forgeext at 711f099 (90) and the driver at 0da0fe6 (175), and the coverage
lint over it finds no uncovered path (124 tests).

Acceptance: the meta-openglow move is a platform change, so the whole
catalog runs again on the image built from these pins.

kas/forgefirm-glowforge.lock.yml

@@ -11,4 +11,4 @@ overrides:
     meta-freescale-distro:
       commit: b9d6a5d9931922558046d230c1f5f4ef6ee72345
     meta-openglow:
-      commit: 71fad52e8ff5695bce3b9c6bc8530a1468426819
+      commit: 2978522f04ae1a15c463c86c5aaa7b568569d3e9

meta-forgefirm/recipes-forgefirm/forgectrl/forgectrl-pin.inc

@@ -4,5 +4,5 @@
 # only SRCREV and PV here - the image manifest leaves *-pin.inc out of the
 # layer content hash because the component entry already identifies the
 # pinned source (forgefirm-image-manifest.bbclass).
-SRCREV = "0dae758cb93e1461034aaa58f4b9fc22edc68367"
-PV = "0.1.27"
+SRCREV = "55bfae9005ecf4578f8778bb3dc7f406bffed762"
+PV = "0.1.28"

meta-forgefirm/recipes-forgefirm/forgeext/forgeext-pin.inc

@@ -4,5 +4,5 @@
 # only SRCREV and PV here - the image manifest leaves *-pin.inc out of the
 # layer content hash because the component entry already identifies the
 # pinned source (forgefirm-image-manifest.bbclass).
-SRCREV = "0000000000000000000000000000000000000000"
+SRCREV = "711f09955c0120f30e142d54b52e47163617fedc"
 PV = "0.1.0"

meta-forgefirm/recipes-forgefirm/forgefirm-app/forgefirm-app-pin.inc

@@ -6,9 +6,9 @@
 # because the component entry already identifies the pinned source
 # (forgefirm-image-manifest.bbclass). The python3-gfhardware recipe in
 # meta-glowforge-bsp pins the same repository; move both together.
-SRCREV = "6cc4f45d311ab451c7d72dee009103e55a749675"
+SRCREV = "021323ddfbdfcd131831f916ad3c0ef1d7a59071"
 
 # Bump PV with every SRCREV move: the hash-derived package version is not
 # monotonic on its own and buildhistory QA fails the build when it sorts
 # backwards.
-PV = "0.1.30+git"
+PV = "0.1.31+git"

meta-forgefirm/recipes-forgefirm/grblhal-glowforge/grblhal-glowforge-pin.inc

@@ -4,5 +4,5 @@
 # changes; keep only SRCREV and PV here - the image manifest leaves
 # *-pin.inc out of the layer content hash because the component entry
 # already identifies the pinned source (forgefirm-image-manifest.bbclass).
-SRCREV = "f93aca89821ae3bf8eee39d5948e53f1edbc20db"
-PV = "0.1.18"
+SRCREV = "0da0fe64ec40baf0be2114e1cdcd0a3767ff9846"
+PV = "0.1.19"