Cap request bodies, close a hole in the gate, fix to_dict and two settings pages

Six fixes that were ours regardless of what the sister site does. Four came out
of our own reviews; two you reported from the settings pages.

MAX_CONTENT_LENGTH was set nowhere. Every upload route caps its own payload, but
each of those checks runs after the body has arrived: the first touch of
request.form or request.files makes Werkzeug parse the whole multipart and spool
the file to a temp file, so a route can reject the content and still have paid
for the transfer and the disk. Three separate reviews found that shape in three
different routes, which makes it a property of the app rather than of any
handler. 128 MB, clearing the 64 MB agent binary with room for the envelope.

The naming gate excluded devnotes with --exclude-dir, which matches a directory
of that NAME at any depth - so a force-added plugins/<plugin>/devnotes/ was
invisible to every check in the file, ADR-015 included. Replaced with a path
anchored post-filter. Verified by planting the same site literal in root
devnotes/ AND in plugins/endpoints/devnotes/: the gate now reports exactly one,
the nested one. Before, it reported none.

BaseModel.to_dict walked __table__.columns and published every one, so a model
without an override published whatever it carried - including columns added
later by someone not thinking about this method. User has no override, so
User.to_dict() returned its bcrypt hash. Nothing calls it in a response path
today, which is luck rather than design. A blanket allowlist would empty the
output of all 34 models relying on the default, so this pins a floor instead:
named secret-bearing columns are never emitted, and a model may extend the set.
Eight tests, including a sweep over every mapped model.

ActionPicker's Esc handlers had .prevent but not .stop, so the event bubbled to
the wrapper and closed the whole picker instead of returning to the monitor list.

The branding page reported "error loading image" on the site and badge logos.
Two bugs stacked. The load failure was real: the preview used the stored value
as a raw src, and that value is root-relative, so under /shopdb or /ops it
resolved against the SERVER root and 404d - siteSettings.js wraps every logo in
withBase() and this page was the one place that did not. With that fixed two of
three were still invisible, because the shipped GE mark is fill="white" for the
dark sidebar and was rendering white-on-white. The preview tile now sits on a
mid-tone checker so artwork of any colour reads against it.

The floor-map levels table ran off the right with its cells crushed - nine
columns of inputs, no scroll wrapper, and .data-table is styled nowhere. My
first attempt reached for the global .table-container and made it WORSE: that
class also sets white-space: nowrap, and a full sentence of hint text lives in
one of the cells, so nowrap forced the table wider still. It now scrolls in a
local wrapper, the hint wraps, and the name input has a width instead of
collapsing to one character.

Suite 2377, frontend 324, gate green.

Scope: product

frontend/src/assets/style.css

@@ -1323,13 +1323,33 @@ td.actions .btn + .btn {
   gap: 0.75rem;
   margin-top: 0.4rem;
 }
+/* A branding preview has to show a logo whose colour we do not control. The
+   shipped GE mark is fill="white" because it lives on the dark sidebar, so on a
+   plain white tile it rendered white-on-white and read as a failed load. A
+   checker ground makes any logo visible - light, dark or transparent - and is
+   the usual convention for previewing artwork with alpha. */
 .map-thumb {
   height: 40px;
+  min-width: 40px;
   border: 1px solid var(--border);
   border-radius: 4px;
-  background: #fff;
+  /* MID-TONE, not white and not near-white. The tile has to show artwork whose
+     colour we do not control: the shipped GE mark is fill="white" for the dark
+     sidebar, the monogram is fill="black". A light ground hides the first, a
+     dark ground hides the second, so the checker sits either side of mid grey
+     and both read against it. */
+  background-color: #9aa1ad;
+  background-image:
+    linear-gradient(45deg, #6f7783 25%, transparent 25%, transparent 75%, #6f7783 75%),
+    linear-gradient(45deg, #6f7783 25%, transparent 25%, transparent 75%, #6f7783 75%);
+  background-size: 12px 12px;
+  background-position: 0 0, 6px 6px;
+  padding: 2px;
+}
+.map-thumb-dark {
+  background-color: #222;
+  background-image: none;
 }
-.map-thumb-dark { background: #222; }
 .settings-success {
   margin-top: 1rem;
   padding: 0.75rem;

frontend/src/views/settings/BrandingSettings.vue

@@ -24,7 +24,7 @@
             >
             <div class="map-upload-row">
               <input type="file" :accept="logo.accept" @change="uploadLogo(logo.kind, logo.key, $event)" :disabled="brandingUploading" />
-              <img v-if="settings[logo.key]" :src="settings[logo.key]" class="map-thumb" :alt="logo.label" />
+              <img v-if="settings[logo.key]" :src="withBase(settings[logo.key])" class="map-thumb" :alt="logo.label" />
             </div>
             <small class="input-hint">{{ logo.hint }}</small>
           </label>
@@ -132,6 +132,12 @@
 <script setup>
 import { onMounted } from 'vue'
 import { useSystemSettings, brandingLogos } from '../../composables/systemSettings'
+// The stored value is root-relative ('/ge-aerospace-logo.svg'). This app is
+// mounted under a base path at every real deployment (/shopdb, /ops), so a raw
+// src resolves against the SERVER root and 404s - which is what "error loading
+// image" was. siteSettings.js already wraps every logo this way for the rest of
+// the app; this preview was the one place that did not.
+import { withBase } from '@/utils/basePath'
 
 const {
   settings, saving, brandingUploading, error, success,

frontend/src/views/settings/FloorMapSettings.vue

@@ -26,6 +26,14 @@
         <button class="btn btn-small" @click="startAddLevel(building)">Add level</button>
       </div>
 
+      <!-- Scroll rather than squeeze: nine columns of inputs do not fit a
+           narrow window, and without a wrapper the table ran off the right of
+           the page with the cells crushed out of shape.
+           NOT the global .table-container - that also sets white-space: nowrap,
+           and the sizing hint below is a full sentence, so nowrap made the
+           table WIDER instead of letting the paragraph wrap. Scroll here, wrap
+           inside the cells. -->
+      <div class="level-table-scroll">
       <table class="data-table">
         <thead>
           <tr>
@@ -46,7 +54,7 @@
             <td>
               <input
                 v-model="level.levelname"
-                class="form-control"
+                class="form-control level-name-input"
                 @blur="renameLevel(level)"
                 :disabled="saving"
               />
@@ -123,6 +131,7 @@
           </tr>
         </tbody>
       </table>
+      </div>
     </div>
 
     <!-- Add building -->
@@ -437,6 +446,17 @@ async function remove(level) {
 }
 
 .mono { font-family: monospace; }
+/* Wide enough that every column keeps a usable width; past this the wrapper
+   scrolls instead of the inputs collapsing to a few pixels. */
+.level-table-scroll { overflow-x: auto; }
+.data-table { min-width: 58rem; }
+/* The sizing note is prose and must wrap; it is the reason the shared
+   table-container wrapper is wrong for this table. */
+.data-table .input-hint { white-space: normal; display: block; max-width: 22rem; }
+.data-table td, .data-table th { vertical-align: top; }
+/* A bare form-control in a table cell collapses to whatever width is left over,
+   which put "Ground floor" in a box one character wide. */
+.level-name-input { width: 11rem; }
 .order-input { width: 4.5rem; }
 .size-input { width: 6rem; }
 .size-fields { display: flex; align-items: center; gap: 0.35rem; }