feat: wide afkitemtime - multiply skill AFK consumable effect

[Catalyst96]

Summary

• Adds wide afkitemtime (configurable, value in hours) that multiplies the instant AFK progress of hold-to-use skill consumables: Blinding Lantern, Half Finished Research Paper (2h/use) and Aethermoon, Charred Bone, Arcane Rock (1h/use)
• Fixes egga/eggan CLI commands outputting primitive values character-by-character
• Replaces direct eval() with indirect (0, eval)() in chng and egga/eggan to evaluate in global scope and eliminate the Rollup EVAL build warning
• Adds CLAUDE.md for contributors using Claude Code, .gitattributes enforcing LF line endings, and excludes .claude/ from version control

How afkitemtime works

The game hardcodes the per-use duration for these items (e.g. 2h). The cheat intercepts the item-use event handlers in ActorEvents_38 and re-invokes the base function N times with the inventory slot restored between calls, until the configured target hours are reached. The first call is synchronous for immediate feedback; extra calls are deferred in batches of 10 via setTimeout to avoid blocking the main thread.

Test plan

• Enable wide afkitemtime, set value e.g. 10 in Config
• Hold-use a Blinding Lantern - should grant 10h of Cavern progress
• Hold-use a Half Finished Research Paper - should grant 10h
• Hold-use Aethermoon / Charred Bone / Arcane Rock - should grant 10h each
• Item tooltip shows configured hours
• egga gga.CurrentMap returns the value, not individual characters
• npm run build:cheats produces no warnings

[MrJoiny]

Thanks for putting this together. I have a few things concerns tho.

• eval change (eval -> (0, eval)):
  Can you explain to me exactly why you want to convert to global-scope eval here? I don't think that's a good enough argument by itself if this is largely to silence a warning. In the long run, I still want to get rid of eval completely, but it's a legacy element for now.

• CLAUDE.md:
  I’d prefer we remove this file. The paper (https://arxiv.org/abs/2602.11988) says that repo-level context files can make tasks take longer, and auto-generated ones can decrease success rates a little, while developer-written ones only help a little. Which also increases inference cost by over 20%.

• installationItemMiscProxy() scope:
  I believe that the new logic that was placed there should be in its own method. The name of the function doesn't exactly fit what it's doing right now, which makes it tougher to follow the flow.

• applyAfkItemMultiCall implementation:
  I'm not completely sold on the present way of batching calls by looping over base calls and using setTimeout. It works, but it seems like it should be easier than it is. I believe we can get the same outcome with an implementation that is easier and does not loop over the base function multiple times.

If it helps you, I can have a look and see if I can find a easier method to increase the time.