build(deps): advance the shared-helpers pin to keep the graph on one commit

[ernysans]

What

Advances the pinned @fabricelements/shared-helpers commit from 31ef85e7 (2026-08-20) to 0c9d53a5 (2026-08-22) — one commit further, a clean descendant (1 ahead / 0 behind).

Scope is package.json + package-lock.json, 8 lockfile lines. Nothing else changed.

Why this commit

Same rule as the previous alignment, applied again rather than restated: a set of pins is coherent only if it names one commit per package across the whole graph, so the target is chosen to match what the rest of the graph resolves — not to be current. This is the follow-on half of that earlier change. The previous commit was what the graph agreed on then; this is what it agrees on now.

Default-branch HEAD was f85e67fd at 2026-08-23T00:25Z, 7 commits further. Not taken — and the reason was re-derived, not carried over from the last pass, because "only docs ahead" is an assessment that has to be re-made per commit rather than inferred from a message prefix.

Those 7 commits touch 4 documentation files and 1 test file, and zero files under src/ or lib/ — so HEAD is runtime-identical to 0c9d53a5. That selector was positive-controlled against the 31ef85e7..0c9d53a5 range, where it reports 31 src//lib/ files, so the zero is a measurement rather than a pattern that structurally cannot match.

Worth the file-by-file count: "documentation-only" would have been slightly wrong. One of the seven is test/user.test.ts. Where HEAD is runtime-identical, matching the graph is the whole tiebreak — and it carries the smaller unreviewed delta as well.

Effect on this repository's tree

Measured 2026-08-23:

	packages	advisories	sharp
before (31ef85e7)	316	10 — 10 moderate, 0 high	0.35.3
after (0c9d53a5)	316	10 — 10 moderate, 0 high	0.35.3

Deliberately unchanged. The sharp upgrade past the libvips fix line landed with the previous pin, so there is nothing left for this one to clear; the remaining 10 moderate advisories are unrelated to this move. A dependency bump that resolves nothing new is the expected shape here, and is reported rather than dressed up.

What does change: the declared contract

The upstream commit adds an allow-list to the user helper that drops caller-supplied authorization fields before a Firestore write, and its Helper class gains a sanitizeProfile member (13 → 14). Both create and add already existed at the previous pin, and add delegates to create, so the new filter sits under both entry points.

Verified in the artifact rather than inferred from the message — creatableProfileFields in the emitted lib/user.js: 0 occurrences at 31ef85e7 → 6 at 0c9d53a5. A measured transition, since the emitted output is what actually executes.

This is bookkeeping, not a security control acquired here

Stating it plainly so it isn't miscounted: this package never executes the helper it now names. The shared-helpers import is type-position-only, tsc elides it, and no @fabricelements specifier appears in any emitted lib/*.js.

For this repository the change keeps the graph on one commit and keeps a duplicate copy out of downstream trees. That is real, and it is separate from applying a runtime control.

Don't mis-measure the dedupe

A consumer resolves this package's transitive pins from whichever commit of this package it itself pins. A consumer still pinned to an older commit here will keep resolving the shared-helpers commit that older commit declares — so copy count in a downstream tree collapses only once that consumer advances its pin of this package too.

Measuring immediately after this merge and finding two copies is the expected reading, not evidence the change did nothing.

Gate exit codes (2026-08-23T00:27Z)

gate	exit
npm ci	0
npm run build	0
git status --porcelain -uall -- lib/	0 lines
npm test	0 — 18 files, 922 tests passed
npm run typecheck	0
npm run lint	0
private-marker guard	0

lib/ is byte-identical after a full clear-and-rebuild — verified, not assumed — so no regenerated output accompanies this change.

The green typecheck is not vacuous: asserting a number against User.InterfaceLinks.behance at the new pin still fails with TS2322, so upstream declarations resolve rather than degrading to any across a commit that rewrote lib/user.d.ts (+107 lines).

Found, deliberately not fixed

• git+ssh:// resolution in the lockfile — still requires a key on every consumer and CI runner. Pre-existing, unchanged here; it wants its own change, since switching the resolution protocol is a lockfile-wide edit rather than something to smuggle into a sha bump.
• 10 moderate advisories remain (@opentelemetry/core <2.8.0, uuid <11.1.1 and dependents). Nothing overridden, pinned around, or silenced to quiet the audit.

No overrides, no any, no @ts-ignore, no assertions added anywhere.