Silence render-disposed spam, unbreak bundled skills, drop board wake

Three independently ugly bugs that all fed the same log flood:

* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
  to stderr via `console.error`. When the worker fans a second
  agent-event past a reloading renderer, we produced thousands of
  identical lines and stalled the main loop on stderr I/O. Added a
  `mainFrame.detached` guard so the send is short-circuited before
  Electron's own catch block fires, and installed a targeted filter in
  `suppress-warnings.ts` (now actually imported from the entry point)
  so the specific `console.error("Error sending from webFrameMain:"…)`
  noise never reaches the terminal. Any other payload still surfaces.

* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
  target when an agent replied to `__board__` — `wakeAgentIfPossible`
  then called `db.getAgent("__board__")`, threw, and the dispatcher
  kept repeating on every send. Strip `HUMAN_SENDER_ID` at
  `resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
  heartbeat so a stray caller (future automation fan-out) cannot
  reintroduce the crash.

* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
  diverges from its parent directory. The four bundled `my-writing-style`
  copies declared `name: writing-style-skill`, so every install emitted
  a warning and dropped the skill. They also lived as orphan gitlinks
  (mode 160000 without .gitmodules), and the global `*.md` gitignore
  hid every other SKILL.md from version control. Fixed the frontmatter
  to match the dir, converted the dangling submodules to plain trees,
  and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
  catalogue instead of silently losing it.

builtin-skills/software-engineer/clean-code/references/fmt-team-rules.md

@@ -0,0 +1,67 @@
+---
+title: Follow Team Formatting Rules
+impact: HIGH
+impactDescription: eliminates style-related code review friction
+tags: fmt, team, consistency, standards
+---
+
+## Follow Team Formatting Rules
+
+A team of developers should agree upon a single formatting style. Every member should use that style. The goal is to make the software have a consistent style, as if written by one person.
+
+**Incorrect (inconsistent styles mixed):**
+
+```java
+// Developer A's style
+public void processOrder(Order order){
+    if(order.isValid()){
+        order.process();
+    }
+}
+
+// Developer B's style
+public void processPayment( Payment payment )
+{
+    if ( payment.isValid() )
+    {
+        payment.process();
+    }
+}
+
+// Developer C's style
+public void processShipment(Shipment shipment) {
+  if (shipment.isValid()) {
+    shipment.process(); }}
+```
+
+**Correct (consistent team style):**
+
+```java
+public void processOrder(Order order) {
+    if (order.isValid()) {
+        order.process();
+    }
+}
+
+public void processPayment(Payment payment) {
+    if (payment.isValid()) {
+        payment.process();
+    }
+}
+
+public void processShipment(Shipment shipment) {
+    if (shipment.isValid()) {
+        shipment.process();
+    }
+}
+```
+
+**Implementation:**
+- Document the team's coding standards
+- Use automated formatters (Prettier, Black, google-java-format)
+- Enforce in CI/CD pipelines
+- Configure IDE to format on save
+
+Your personal style preferences are less important than team consistency.
+
+Reference: [Clean Code, Chapter 5: Formatting](https://www.oreilly.com/library/view/clean-code-a/9780136083238/)