[NaySurGithub]

What

ItemBookComponent and ItemBlockDynamicPropertiesComponent now behave like the game once the ItemStack they were taken from is gone:

• every member throws InvalidItemStackError with the game's message, Failed to <get property|set property|call function> '<member>' due to the ItemStack being invalid (has the ItemStack been removed?).
• itemType on the error is the ItemType the stack had when the component was taken
• Component.isValid returns false; typeId still answers

Before this change Falcon never threw InvalidItemStackError, so itemType was never readable, and the component kept its stack alive forever.

How it was checked

Client 26.60 in IDA:

• the item component constructor stores a weak handle to the script ItemStack plus a copy of the stack's ItemType handle; it drops the strong handle it was given
• the component's validity check only tests that weak handle against the script object registry
• every book getter/method checks it first and, on failure, builds InvalidItemStackError from the action kind (get property / set property / call function), the member name and the stored ItemType; the message format string and the ItemStack noun were read from the binary
• the .d.ts of 2.12.0-beta.1.26.60 list InvalidItemStackError on every member of these two classes, and only on them

Since the script ItemStack owns its native object, a chained temporary (new ItemStack(id).getComponent("book").pageCount) leaves the component dangling once the statement's temporary is released. Two existing tests used that pattern and now keep the stack in a variable.

Tests: ScriptApiTests covers a dead book (getter and method), a dead block-properties component, isValid on both and a live component.

Not built locally (syntax-checked with clang++ -fsyntax-only); CI runs on the branch.

AI disclosure

Code, research in the game binary and this description: Claude Opus 5.5 (claude-opus-5-5).