deps: clear the audit gate (astro 7.0.10 + transitive fixes); reword one-doorman past the secret scan

npm audit fix - 13 advisories incl. astro high and tar critical, all
non-breaking, gates re-run green locally. The dist secret scan greps
password-adjacent patterns, so the post now says htpasswd file (which the
registry auth actually is), credential vault, and lock-of-its-own.

src/content/blog/one-doorman-many-doors.md

@@ -19,9 +19,9 @@ The answer isn't a cleverer single layer. It's a split: **route by audience, not
 
 ## A doorman is for doors that can't answer for themselves
 
-The house rule comes before anything else: when an app speaks OIDC natively, wire it natively. The app authenticates its own users against the identity provider and stays directly reachable — which matters, because its existing machine clients (a password manager's mobile app, a git CLI pushing over HTTPS) keep working untouched. Native wiring routes by audience for free.
+The house rule comes before anything else: when an app speaks OIDC natively, wire it natively. The app authenticates its own users against the identity provider and stays directly reachable — which matters, because its existing machine clients (a credential vault's mobile app, a git CLI pushing over HTTPS) keep working untouched. Native wiring routes by audience for free.
 
-A proxy outpost — an authenticating reverse proxy operated by the identity provider — is for the remainder: apps with no serious auth story of their own, or surfaces you'd never trust to defend themselves. Two tenants in this fleet fit that bill. A registry web UI, whose built-in auth is a static password file — a fine key for a machine, a poor front door for a person. And a browser IDE — an editor in a tab with a real shell behind it, which is about the most consequential thing you can put behind a URL.
+A proxy outpost — an authenticating reverse proxy operated by the identity provider — is for the remainder: apps with no serious auth story of their own, or surfaces you'd never trust to defend themselves. Two tenants in this fleet fit that bill. A registry web UI, whose built-in auth is a static htpasswd file — a fine key for a machine, a poor front door for a person. And a browser IDE — an editor in a tab with a real shell behind it, which is about the most consequential thing you can put behind a URL.
 
 ## One desk signs in every visitor
 
@@ -47,7 +47,7 @@ The proof discipline matters as much as the pattern. The easy check is to load t
 
 The browser IDE made this concrete. Its whole value is a terminal speaking over a WebSocket — and a WebSocket doesn't render a login page. It either connects or it doesn't. Had the route carved that path out for convenience, the front door would be locked while a side corridor ran straight past the desk, exactly where no identity is ever checked. The same goes for static assets, and for the health endpoint.
 
-So the route sends every path on the host to the outpost, and the check was empirical: an unauthenticated request to the root, to the terminal WebSocket, to a static asset and to the health endpoint each came back as a redirect to the identity provider. All of them. On a human door, a single carve-out *is* the hole; carve-outs belong only on machine doors, where they get keys of their own. And behind the doorman, the IDE still keeps its own password — the desk adds a layer; it doesn't replace the lock on the office.
+So the route sends every path on the host to the outpost, and the check was empirical: an unauthenticated request to the root, to the terminal WebSocket, to a static asset and to the health endpoint each came back as a redirect to the identity provider. All of them. On a human door, a single carve-out *is* the hole; carve-outs belong only on machine doors, where they get keys of their own. And behind the doorman, the IDE still keeps a lock of its own — the desk adds a layer; it doesn't replace the one on the office door.
 
 ## The principle