Url resolution for CSS referenced images is not working properly

Resolved by adding upstream-parity artifact upload + asset_library sync to our push pipeline, plus a preflight ban on the unsupported CSS `url()` pattern.

**Root cause was bigger than the ticket framing.** The investigation revealed our `scripts/canvas-api.mjs` push pipeline reads `dist/canvas-manifest.json` for validation only — it never uploaded the manifest's `vendor` / `local` / `shared` entries to `/canvas/api/v0/artifacts/upload`, and never PATCHed `/canvas/api/v0/config/asset_library/global` to register them. That meant any component using `import bg from './hero.jpg'` would build cleanly but deploy with a broken asset reference: vite's compiled JS calls `import.meta.resolve("@/components/.../hero.jpg")`, but the Canvas server's importmap had no entry for that specifier because we never registered it.

**Supported pattern (new):**
```jsx
import bg from './file.svg';
export default () =>

;
```
The push pipeline now uploads each manifest entry to `/canvas/api/v0/artifacts/upload`, PATCHes `/canvas/api/v0/config/asset_library/global` with the resulting `{name, uri}` mapping, and the Canvas server's per-component importmap (visible in `js_header`) resolves `import.meta.resolve()` to `/sites/default/files/canvas/assets/?1.4.0`.

**Unsupported pattern (banned):**
```css
.hero { background-image: url('./file.svg'); } /* will fail preflight check-14 */
```
CSS URL refs are banned because Canvas's importmap only governs JS resolution — CSS asset URLs go through the browser's stylesheet parser, which never consults the importmap. A CSS-aware path would need server-side coordination (out of scope; tracked as a future Canvas feature).

**What landed (commits):**

- `c306c67` docs(3588764): spec + implementation plan for canvas asset pipeline
- `c40529a` feat(3588764): upload-artifacts module for canvas asset pipeline
- `2bb68af` fix(3588764): harden upload-artifacts against degraded responses
- `26a4288` feat(3588764): asset-library module — PATCH /asset_library/global
- `4a0aeca` fix(3588764): asset-library + upload-artifacts hardening pass
- `5224445` feat(3588764): wire artifact-upload + asset-library-sync into cmdPush
- `a32d357` fix(3588764): add 503 retry to cmdPush's client2 adapter
- `38bf2c6` fix(3588764): per-endpoint 503 backoff in client2 (10s/30s/60s for asset_library)
- `1e79a3f` feat(3588764): preflight check-14 — ban relative CSS url() in components
- `38a8d9c` docs(3588764): gotchas + component-builder rules for asset pipeline
- `02ff2c5` docs(3588764): asset pipeline architecture + usage doc
- `e764c64` test(3588764): grep gate for asset pipeline docs + modules

Verified end-to-end against the dev Acquia Source instance via a probe component (`asset_probe` with a JS-imported SVG) — server-generated importmap correctly mapped the specifier to the served URL:

```
@/components/asset_probe/probe-bg.svg → /sites/default/files/canvas/assets/probe-bg-BymbtAI0.svg?1.4.0
```

**Three findings worth noting in this thread for upstream eyes:**
1. The `/canvas/api/v0/config/asset_library/global` PATCH endpoint requires arrays-of-objects (`assets: [{name, uri}]`). Sending a key-value map returns HTTP 503 with a generic "Technical Difficulties" page that masks the validation failure. Worth surfacing this in docs.
2. `POST /canvas/api/v0/config/js_component` also returns 503 (instead of a 4xx with details) when `props` schema is malformed — e.g., top-level `type: object` instead of nested `properties: {}`. Same UX problem: the actual cause is hidden.
3. CSS `url()` end-to-end could be made to work if the server emitted a CSS preprocessing step that consulted the same asset_library map. Filing as a separate enhancement candidate.