fix: address Copilot review round 14 on #2248

**The TUI ignored `incomplete`.** Round 12 added that field precisely so a
consumer could tell "not fully checked" from a real failure, and then the one
client that reads the report did not consume it — which made the field
decorative. The pane shows an Incomplete: block with the report's own reason,
and the status line reads INCOMPLETE rather than FAILED.

It sits ABOVE the manifest, not beside the status line: it explains the list
that follows — only the first N rows were fetched, the rest stay marked `·`
because nobody looked at them — and below a 512-row manifest it would be
off-screen, which is the same as absent. Found by writing the test, whose
first version asserted against a 600-entry fixture and could see neither
string. The test triggers truncation through the BYTE budget instead, so the
manifest stays three rows and the assertions measure the pane rather than the
test's viewport.

**The capped self-entry was reported under the wrong URI.** A manifest may
write its self-entry in a normalized-equivalent form; the fallback recorded
`entry.uri`, so manifest rows keyed on the declared spelling matched nothing
while the normalized extra-files filter suppressed it as already covered. The
verdict existed in the report and appeared nowhere on screen. Recorded under
`declaredSelf.uri` now.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ND46Ci64DC3tzBy9aG81Nc
Signed-off-by: cliffhall <cliff@futurescale.com>

clients/tui/__tests__/SkillsTab.test.tsx

@@ -750,6 +750,50 @@ describe("SkillsTab (#2248)", () => {
     );
   });
 
+  it("says a verification was INCOMPLETE rather than merely failed", async () => {
+    // `verifySkills` sets `incomplete` so a consumer can tell "not fully
+    // checked" from a real failure; printing only "Verification FAILED" threw
+    // that distinction away, and the entries beyond the cap stayed marked `·`
+    // with nothing explaining why (Copilot).
+    //
+    // Truncation is triggered by the BYTE budget rather than the 512-entry one
+    // so the manifest stays three rows long: a 512-row pane pushes the status
+    // line off the frame, which would make this assert the test's viewport
+    // rather than the pane's behaviour.
+    const big = "x".repeat(6 * 1024 * 1024);
+    const fat: SkillEntry = {
+      uri: "skill://fat/SKILL.md",
+      frontmatter: { name: "fat", description: "Understates its sizes" },
+      resources: Array.from({ length: 3 }, (_, i) => ({
+        uri: i === 0 ? "skill://fat/SKILL.md" : `skill://fat/f${i}.md`,
+        digest: CLEAN_DIGEST,
+        size: 1,
+      })),
+    };
+    const { lastFrame, stdin } = render(
+      <SkillsTab
+        skills={[fat]}
+        pageCount={1}
+        inspectorClient={mockClient(
+          vi.fn().mockImplementation(async (uri: string) => ({
+            result: { contents: [{ uri, text: big }] },
+          })),
+        )}
+        width={160}
+        height={40}
+        focusedPane="list"
+      />,
+    );
+    stdin.write(ENTER);
+    await tick();
+    await tick();
+    const frame = lastFrame() ?? "";
+    expect(frame).toContain("Incomplete:");
+    expect(frame).toContain("actually served");
+    expect(frame).toContain("Verification INCOMPLETE");
+    expect(frame).not.toContain("Verification FAILED");
+  });
+
   it("shows a read failure the manifest does not cover", async () => {
     // A dynamic skill has no manifest rows, so the synthetic read-error row
     // `verifySkills` records for its own SKILL.md was rendered nowhere and the