rdf-1 transform: derived JSON-LD is an expanded top-level array, and an unparseable source is refused at PUT instead of degrading (JLWSR-AB-2/CAP-9/RT-9/RT-10)

**Branch:** `feat/lws` @ `0f2082c`. Found by the JLWS conformance suite — scoreboard `lws-spec` `feat/rs-baseline` `test-suite/reports/solid-server-rs-baseline-2026-07-06.md` (vector pin `lws-spec@f2e081d`). Two findings on the claimed `transform/rdf-1` capability (the SD advertises both ContentNegotiation pairs), grouped because both live in the transform/authoritative-bytes seam:

## 1. Derived JSON-LD representation is an expanded top-level ARRAY

`rdf-transform/advertised-conneg-honoured`: `GET ` with `Accept: application/ld+json` returns

```json
[{"@id":"…#me","http://www.w3.org/1999/02/22-rdf-syntax-ns#type":[…],…}]
```

— expanded form with a **top-level array**. The vector requires a JSON **object** (`jsonIsObject`) as the derived representation. The `Content-Type`, `Vary: Accept`, and per-representation-ETag legs all pass (`per-representation-etags-differ` is green), so this is purely the serialization shape out of the oxjsonld path. Statement fallout: JLWSR-AB-2 / JLWSR-CAP-9 / JLWSC-CT-4 aggregate to fail through this case even though their specific facets (Vary, honest advertisement) are otherwise satisfied — fixing the body shape recovers all three.

## 2. Unparseable RDF source is refused at write time

`rdf-transform/unparseable-source-degrades-per-resource` could not even realise its state: `PUT` of a deliberately broken `.ttl` (Content-Type `text/turtle`) → **400** — the write path validates RDF and refuses. Under JLWS the stored bytes are **authoritative** whatever they parse as: the write stores the bytes, the native-type `GET` serves them byte-exact, and only the **derived** representations degrade per-resource — **JLWSR-RT-9/RT-10 (MUST)**: "If the authoritative representation fails to parse under its stored media type, the server MUST answer requests for derived representations with 406 Not Acceptable carrying a problem details body of type …/problems/unparseable-source" (per-resource, not storage-wide). Note byte-exactness itself is green (`rdf-transform/stored-bytes-byte-exact` passes), so this is only the write-path validation posture with LWS on; the Solid track's validate-on-write behaviour flag-off can stay as-is.

---
🤖 PSS agent — @jeswr's agent for `prod-solid-server` / the Solid app+Pod-Manager suite
Model: claude-fable-5

Start with the lws-spec conformance vectors named in the report, especially rdf-transform/advertised-conneg-honoured and rdf-transform/unparseable-source-degrades-per-resource. Trace the transform/authoritative-bytes seam through the oxjsonld path and PUT validation, then verify object-shaped JSON-LD, byte-exact native GETs, and the required 406 problem-details response for unparseable sources.

Written by the indexing model from the issue text.