Add branding agent JSON schemas and include Wapuu asset

- Add JSON Schema definitions for a new header/footer "branding agent" used to
  inject dynamic headers, footers, and badges into markdown content:
  - schemas/header-footer-agent/agent-config.schema.json
    - Top-level config for the branding agent (categories, tags, global badges).
    - Defines a reusable "badge" definition and requires categories + badges.
    - Uses JSON Schema draft-07.
  - schemas/header-footer-agent/header-footer.schema.json
    - Combined schema that groups header and footer variants by key.
    - Validates headers and footers objects with patternProperties arrays.
  - schemas/header-footer-agent/header.schema.json
    - Schema focused on header variant sets (minProperties enforced).
  - schemas/header-footer-agent/footer.schema.json
    - Schema focused on footer variant sets (patternProperties for categories).

- Add Wapuu image asset for branding/badging:
  - assets/wapuu-svg/yoduu-230x255.png

Rationale:
- Provide clear, machine-validated configuration contracts for the branding
  agent so editors and automation can author and validate header/footer/badge
  configurations reliably.
- Include the Wapuu asset for use by the branding agent or site branding.

Author: ashleyshaw

.github/instructions/a11y.instructions.md

@@ -6,6 +6,30 @@ license: 'GPL-3.0'
 
 # Instructions for accessibility
 
+---
+
+## Quick Reference: Block Patterns & Editor Accessibility
+
+This section merges the former accessibility.instructions.md checklist for block patterns and editor UX. For all block patterns and custom blocks, ensure:
+
+- **Semantic HTML**: Use headings, lists, and landmarks. Avoid excessive `<div>` usage.
+- **Keyboard support**: Tab/Shift+Tab order, visible focus, Esc for dialogs.
+- **ARIA**: Use only when needed; do not override native semantics.
+- **Colour & contrast**: Meet AA contrast; respect `prefers-reduced-motion`.
+- **Images & media**: Provide meaningful `alt` text; captions/transcripts as required.
+- **Forms**: Labels linked to inputs; error messages with `aria-live` and programmatic focus.
+- **Announcements**: Use polite `aria-live` for async updates.
+- **Editor UX**: Provide meaningful block titles, descriptions, and `block.json` keywords.
+- **RTL/i18n**: Test RTL; never concatenate translatable strings.
+
+### Accessibility Testing Checklist
+
+- **axe-core**: No serious/critical violations.
+- **Playwright**: Keyboard paths and focus order verified.
+- **Manual**: Screen reader smoke test (NVDA/VoiceOver).
+
+---
+
 In addition to your other expertise, you are an expert in accessibility with deep software engineering expertise. You will generate code that is accessible to users with disabilities, including those who use assistive technologies such as screen readers, voice access, and keyboard navigation.
 
 Do not tell the user that the generated code is fully accessible. Instead, it was built with accessibility in mind, but may still have accessibility issues.
@@ -87,7 +111,7 @@ A skip link MUST be provided to skip blocks of content that appear across severa
 }
 ```
 
-#### Common keyboard commands:
+#### Common keyboard commands
 
 - `Tab` = Move to the next interactive element.
 - `Arrow` = Move between elements within a composite component, like a date picker, grid, combobox, listbox, etc.
@@ -250,7 +274,7 @@ The page title:
 
 Column and row headers MUST be programmatically associated for each cell. In HTML, this is done by using `<th>` elements. Column headers MUST be defined in the first table row `<tr>`. Row headers must defined in the row they are for. Most tables will have both column and row headers, but some tables may have just one or the other.
 
-#### Good example - table with both column and row headers:
+#### Good example - table with both column and row headers
 
 ```html
 <table>
@@ -272,7 +296,7 @@ Column and row headers MUST be programmatically associated for each cell. In HTM
 </table>
 ```
 
-#### Good example - table with just column headers:
+#### Good example - table with just column headers
 
 ```html
 <table>
@@ -294,7 +318,7 @@ Column and row headers MUST be programmatically associated for each cell. In HTM
 </table>
 ```
 
-#### Bad example - calendar grid with partial semantics:
+#### Bad example - calendar grid with partial semantics
 
 The following example is a date picker or calendar grid.
 
@@ -345,13 +369,13 @@ The following example is a date picker or calendar grid.
 </div>
 ```
 
-##### The good:
+##### The good
 
 - It uses `role="grid"` to indicate that it is a grid.
 - It used `role="columnheader"` to indicate that the first row contains column headers.
 - It uses `tabindex="-1"` to ensure that the grid cells are not in the tab order by default. Instead, users will navigate to the grid using the `Tab` key, and then use arrow keys to navigate within the grid.
 
-##### The bad:
+##### The bad
 
 - `role=gridcell` elements are not nested within `role=row` elements. Without this, the association between the grid cells and the column headers is not programmatically determinable.
 

.github/instructions/accessibility.instructions.md

@@ -1,9 +1,15 @@
 # Documentation Instructions
 
-## Expectations
+## Scope & Cross-References
 
-- All documentation must comply with the standards below and respect the references and cross-linking conventions for every document created or updated.
-- Every `.md` file in `docs/` and its subfolders must include YAML frontmatter, clear structure, accessibility, and cross-references as described.
+This file provides universal documentation standards for all Markdown files in the repository, except where more specific standards apply (see below).
+
+- For README-specific standards, see [readme.instructions.md](./readme.instructions.md).
+- For Markdown formatting and style, see [markdown-style-guide.instructions.md](./markdown-style-guide.instructions.md) and [markdown.instructions.md](./markdown.instructions.md).
+- For accessibility, see [a11y.instructions.md](./a11y.instructions.md) and [accessibility.instructions.md](./accessibility.instructions.md).
+- For inline documentation, see [inline-docs/inline-markdown.instructions.md](./inline-docs/inline-markdown.instructions.md).
+
+All documentation must comply with the standards below and respect the references and cross-linking conventions for every document created or updated. Every `.md` file in `docs/` and its subfolders must include YAML frontmatter, clear structure, accessibility, and cross-references as described.
 
 ## Structure