✨ feat: enhance medialib image handling and add asset URL resolution

- Implemented `resolveApiAssetUrl` function to normalize asset URLs based on API base.
- Updated `MedialibImage` component to utilize new asset URL resolution and added support for alt text and class properties.
- Enhanced image loading behavior with improved width measurement and focal point handling.
- Added placeholder image handling and improved accessibility with alt text.
- Introduced new test script for auditing broken links in skill documentation.
- Expanded seeded test content to include medialib entries and updated related tests for pagebuilder previews.
- Improved global setup and teardown logging for clarity on seeded content management.

.agents/skills/permissions-and-editor-workflows/SKILL.md

@@ -89,6 +89,23 @@ Important behavior:
 
 This means field permissions are not mere UI hints. They are enforced server-side.
 
+## Config delivery matters to the admin UX
+
+Field permissions also affect what the client receives from the project config.
+
+Important behavior for non-admin users:
+
+- effective readonly information is exposed through `yourPermissions[collection].readonlyFields`
+- statically hidden field definitions are removed from `fields[]`
+- `hiddenFields` arrays are not delivered as-is to non-admin clients
+- eval-based field rules stay relevant because they depend on document context
+
+Implication:
+
+- Nova and other clients should reflect the real config/permission output instead of pretending every field is always present and editable
+
+If later agents debug “missing” fields in the admin, check permission-shaped config delivery before assuming the admin UI is broken.
+
 ## Dynamic field rules
 
 Use eval-based field rules when permissions depend on document state.
@@ -101,6 +118,12 @@ Typical examples:
 
 Use these rules to model real editorial transitions, not to create confusing surprises.
 
+For each eval-based rule, later agents should be able to name:
+
+- one allowed write scenario
+- one denied write scenario
+- the document state that flips the rule
+
 ## Admin UX must reflect permission reality
 
 If a field is hidden or readonly for a role, the Nova configuration and layout should support that reality.
@@ -114,6 +137,29 @@ Recommended patterns:
 
 Server permissions are authoritative, but poor admin layout can still create a bad workflow.
 
+## Permission matrix before YAML
+
+Before writing or changing permission sets, write down a small matrix for the real actors.
+
+Typical matrix columns:
+
+- actor or role
+- collections they can read
+- collections they can write
+- fields hidden from them
+- fields readonly for them
+- machine/token access they need
+
+Typical actors:
+
+- public
+- editor
+- reviewer or publisher
+- admin
+- machine token or integration
+
+This avoids permission YAML that is locally correct but globally incoherent.
+
 ## Tokens and integrations
 
 Remember that token-based integrations can have their own permission sets.
@@ -178,9 +224,11 @@ After changing permissions or editor workflows, verify all of these:
 1. Collection methods match the intended role model.
 2. Hidden and readonly field behavior is correct on API reads/writes.
 3. Dynamic eval rules behave correctly for the intended document states.
-4. Nova forms remain usable for the non-admin roles that actually work there.
-5. Token/integration permissions are narrower than admin access when possible.
-6. `yarn validate` stays clean.
+4. At least one representative allowed write and one denied write were checked for each important workflow state.
+5. Non-admin config delivery still makes sense for the admin UI and field layout.
+6. Nova forms remain usable for the non-admin roles that actually work there.
+7. Token/integration permissions are narrower than admin access when possible.
+8. `yarn validate` stays clean.
 
 ## What an LLM should inspect first