fix(access-policy): preserve user-supplied id in the policy builder

[aleksandrkislitsyn]

Fixes HealthSamurai/sansara#8074.

Problem

Creating an AccessPolicy in the resource browser with an explicit id (e.g. id: test-id) produced a resource with a different, server-assigned id.

Root cause

The AccessPolicy builder (builder-content.tsx) stripped id/resourceType/meta out of the editable text and kept them in separate state. On every keystroke, handleTextChange re-merged the parsed text with id: accessPolicy.id.

On the create page the initial resource has no id, so accessPolicy.id is undefined. The typed id was therefore overwritten with undefined, and the create request went out with no id — so the server assigned a random one. (Confirmed against a running Aidbox: a create request that does carry a body id honors it; the UI was sending none.)

This was specific to the AccessPolicy custom builder — the generic resource editor sends the full edited text and was already correct.

Fix

Stop stripping id. It now stays visible and editable in the editor, and flows from the parsed text into the saved resource:

• Create: typing id: test-id keeps the id in the editor and creates the policy with test-id.
• Edit: existing policies show their id; the update still uses the route id for the URL, so the id cannot be changed by editing.

resourceType (fixed for AccessPolicy) and meta (server-managed) remain stripped.

Testing

• pnpm biome check — clean.
• pnpm typecheck — no new errors (two pre-existing notebook-chart/fold-data.ts codemirror errors on master are unrelated).
• Manually verified in the dev server: create an AccessPolicy with id: test-id → id stays visible in the YAML and the resource is saved with that id.

🤖 Generated with Claude Code

[aleksandrkislitsyn]

Note on the failing audit check

The audit job failure is pre-existing and unrelated to this PR. CI runs pnpm audit --audit-level=high, which queries the live advisory database at run time. It's flagging transitive dependencies only:

• postcss (via vite) — GHSA-r28c-9q8g-f849
• seroval (via @tanstack/react-router) — GHSA-mv8w-475r-vwqw
• js-yaml — GHSA-pm4m-ph32-ghv5

This PR changes a single component (builder-content.tsx) and touches no dependencies or lockfile (git diff master... shows only that one file). Earlier master/PR runs passed only because they ran before these advisories were published — same lockfile, newly flagged.

build, lint, and typecheck all pass. The dependency advisories should be addressed by a separate lockfile-bump PR (there's already an audit-fixes branch), not folded into this fix.

[aleksandrkislitsyn]

Update: pushed 8638ec7 to fix the audit check in this PR.

These advisories were newly published against deps already in the lockfile (not introduced here). Since no existing commit fixed them, I added pnpm overrides:

• postcss → >=8.5.18 (GHSA-r28c-9q8g-f849)
• seroval → >=1.5.3 (GHSA-mv8w-475r-vwqw, via @tanstack/react-router)
• js-yaml → 5.2.2 (GHSA-pm4m-ph32-ghv5)

Also consolidated three conflicting js-yaml overrides (which were forcing the direct ^4.1.1 dep up to a vulnerable 5.2.1) into one targeting 5.2.2. Only .load()/.dump() are used, so the 5.2.1 → 5.2.2 patch bump carries no API risk.

pnpm audit --audit-level=high now reports no known vulnerabilities; typecheck and lint remain green.