[feat] Scope teamwiki recall by project, like docs

[SaulMoro]

Problem

In a team repo with manifest/projects.yaml, a checkout set up with --project svc-a gets wiki pages from every codebase in teamai recall, svc-b's included. Learnings and docs are filtered by the active project. The wiki is not, and no doc says whether it should be.

recall(query)                                            src/recall.ts
  wikiRoot = <clone>/teamwiki                            :557
  queryCodeKnowledge(query, { wikiRoot, limit, depth })  :599   no project input
    loadWikiPages(wikiRoot, depth)                       src/code-knowledge-recall.ts:447
      readdir(evidence/code), every <slug>/              :253-265   no filter

There is nothing to filter by. evidence/code/<slug>/ is named by codebase (teamai codebase --project <slug>), not by manifest project, and projects.yaml has no resource type that ties a slug to a project (src/manifest-schema.ts:74, src/projects.ts:16). The design lists what stays unscoped after #707, packages and culture.md (docs/designs/multi-project-management.md:545), and teamwiki is not on that list. The result is labelled [docs] … [project] (src/recall.ts:612), so it reads as a project doc.

Reproduction:

1. Team repo with manifest/projects.yaml declaring svc-a, and teamwiki/evidence/code/svc-b/modules/isolation.md holding the word narwhal.
2. In a git repo, teamai init <team-url> --provider git --agent claude --project svc-a.
3. teamai recall narwhal --depth lookup:

[1/1] [docs] narwhal svc-b module [project]
File: ~/.teamai/projects/<slug>/team-repo/teamwiki/evidence/code/svc-b/modules/isolation.md

Declaring docs: [svc-b] on project svc-b withholds docs/svc-b/ in the same run, so the manifest loads and filters. Only the wiki ignores it.

Proposed Solution

A hand-declared wiki axis with the same rule as docs (#707). A slug that some role or project lists under resources.wiki reaches only the directories where it is active. An undeclared slug stays shared, so existing teams see no change.

# manifest/projects.yaml
projects:
  - id: svc-a
    resources: { docs: [svc-a], wiki: [svc-a] }
  - id: svc-b
    resources: { docs: [svc-b], wiki: [svc-b] }

 src/manifest-schema.ts
-HAND_DECLARED_RESOURCE_TYPES = ['env', 'hooks', 'mcp', 'models', 'docs']
+HAND_DECLARED_RESOURCE_TYPES = ['env', 'hooks', 'mcp', 'models', 'docs', 'wiki']   // + wiki: OptionalNamespaceList
 src/resource-namespaces.ts
+  inactiveWikiNamespaces = declared wiki namespaces (roles ∪ projects) − active   // as inactiveDocsNamespaces
 src/code-knowledge-recall.ts
+  QueryCodeKnowledgeOptions.withheldCodebases; loadWikiPages skips those evidence/code/<slug>/ (case-folded)
 src/recall.ts:599
+  withheldCodebases = hasWiki ? (await resolveResourceNamespaces(wikiConfig))?.inactiveWikiNamespaces ?? [] : []

An unreadable manifest throws inside the existing try, so the wiki stays out, the same fail-closed rule docs follow. Older CLIs ignore the key with a warning (0.22.0 prints declares unknown resource type "wiki", which this CLI ignores). I tried it on main at 417e704. It is +30 −7 in 4 files. A recall() test with a real manifest and a real teamwiki/ fails before the change and passes after, and the unit suite passes. The docs (usage guide in both languages, the design doc, skill-data/wiki phase 0) need a line on declaring the slug.

Alternatives Considered

If the wiki is meant to be team-wide, the fix is a doc change instead: add teamwiki to the "still unscoped" sentence in the design doc and to the usage guide's multi-project section. Whether the wiki should follow projects is for the maintainers to decide.

Additional Context

Found while testing multi-project isolation for #908, in a sandbox with the real 0.22.0 CLI. With wiki: [svc-a] and wiki: [svc-b] declared, 0.22.0 still returns the svc-b page, and a build with the change above does not. Not checked: --depth route, which serves one team-wide router.md, and graph-edge relatedFiles, which can still name another codebase's source paths.