fix: scope lorebook activation flags per entry

[miladiashe]

PR Checklist

• Required Checks
  • Have you added type definitions?
  • Have you tested your changes?
  • Have you checked that it won't break any existing features?
• If your PR uses models¹, check the following:
  • Have you checked if it works normally in all models?
  • Have you checked if it works normally in all web, local, and node-hosted versions? If it doesn't, have you blocked it in those versions?
• If your PR is highly AI generated², check the following:
  • Have you understood what the code does?
  • Have you cleaned up any unnecessary or redundant code?
  • Is it not a huge change?
    • We currently do not accept highly AI generated PRs that are large changes.

Summary

로어북 데코레이터 @@keep_activate_after_match, @@dont_activate_after_match 가 의도하지 않은 로어북까지 참조용 변수를 만드는 문제 수정

Related Issues

None

Changes

기존 코드대로면 @@keep_activate_after_match 데코레이터가 있는 로어북을 처리한 뒤, 다음 로어북에서도 데코레이터가 없음에도 내부 변수를 생성하는 문제가 있습니다.
데코레이터가 없으면 실제로 참조하지는 않지만 이렇게 각 로어북 체크할 때마다 keepActivateAfterMatch, dontActivateAfterMatch를 새로 초기화하는 편이 합리적이라고 생각해 PR 올립니다.

Impact

실제 기능에는 변화가 없습니다.

Additional Notes

기존에 생긴 내부 변수가 정리되지는 않습니다.

Footnotes

1. Modifies the behavior of prompting, requesting, or handling responses from AI models. ↩

2. Over 80% of the code is AI generated. ↩

[cubicj]

I reproduced the leak against current main before anything else. With four always-active entries where only the first carries @@keep_activate_after_match and the third carries @@dont_activate_after_match, main stamps six internal vars, the two legitimate ones plus junk on every entry that activates after a flag turns on, and the da-decorated entry even picks up a stray __internal_ka_ var. This head stamps exactly the two legitimate ones with identical actives output, and the DevTool variable list stops accumulating the junk.

The junk stamp can also change activation within a single scan when two entries share an id, which the child link feature and repeated lorebook imports both produce. On main a plain entry's leaked __internal_ka_ stamp gets read by a later decorated entry with the same id, force-activating it with no key match. I ran that scenario on both sides and main activates three entries where this head activates two. So this fixes a real activation bug in the shared-id case, not just variable noise.

On the leftover vars you noted, they only matter for entries with a stable id. An id-less entry keys its var on a content hash, so adding a decorator later changes the key and the old junk is never read. pnpm check, pnpm test, and pnpm build are clean on this head, it merges clean against current main, and the hunks are disjoint from #1532's.

Approving — thanks for the contribution!

[sub-hub]

Thanks for the PR.
Moving the two flags inside the loop makes them reset per entry, so a keep/dont_activate_after_match on one entry no longer carries over to the entries after it.
Some bots prompts may change slightly because of this, but that's the intended behavior.