fix(projects): reclaim the last project rule after projects remove

[jeff-r2026]

Problem

After teamai projects remove <id>, a member whose only delivered team rule came from that project can retain the deployed rule after teamai pull --force. This violates the remove/reclaim acceptance criterion in #756 and the behavior documented in #774.

Evidence

• In PR feat(projects): add admin commands to manage the projects manifest (#756) #774, RulesHandler.pullAllRules() returns immediately when the filtered rule set is empty, before its stale-file cleanup: src/resources/rules.ts:442-455. The comment explains that the guard protects user-authored rules.
• The PR's remove e2e seeds a shared rule at line 137 and asserts that it remains at lines 200-212. The filtered set therefore stays nonempty and exercises the stale-file sweep. It does not cover removal of the last applicable rule.
• The usage guide in PR #774 says the next pull cleans up deployed project rules, provided project content remains in the team repo. Keeping the content does not bypass the empty-set return.

Reproduction case

1. In a team repo, define project alpha with one rule in its exclusive knowledge namespace. Keep that rule in the repo. Do not define any shared or role-delivered rule for the member.
2. Activate alpha in a member directory and run teamai pull --force; confirm the rule is deployed locally.
3. Remove alpha from manifest/projects.yaml using teamai projects remove alpha, merge the manifest change, then run teamai pull --force in the same member directory.
4. The project rule is no longer selected, but pullAllRules() sees zero rules and returns before removing the local copy.

This is a code-path finding; the exact zero-rule scenario is not covered by the PR's real-CLI test.

Expected behavior

The next pull reclaims rules previously deployed by TeamAI for the removed project, including when the desired rule set is empty, while preserving user-authored or locally modified rules.

Suggested verification

Extend the real-CLI remove e2e in #774 with a case that has no shared or role rule. Assert that the project rule disappears after pull. Add a guard assertion that a personal rule in the same tool directory survives. Preserve the existing data-safety behavior rather than sweeping every file when the desired set is empty.

Related: #756, #774.

[huiq777]

I'll take this, since it's the follow-up I flagged in #774. Plan: when the desired rule set is empty but the team repo still has rules, only reclaim local rule files that match a team-repo rule and are unchanged from its source. Personal and locally edited rules stay, like the skills cleanup. I'll also extend the remove e2e with a no-shared-rule case plus a personal-rule guard, as suggested.