feat(npc): let owners grant CORE integrations to NPCs

[omjeem]

Summary

Lets a town owner grant specific CORE integrations (and optionally specific actions within them) to individual NPCs, so characters can act on the resident's connected tools during chat — not just talk about them.

• Guardrail: integration grants can be marked owner_only, which hides those tools from the model entirely when the speaker isn't the owner (NPCs run on the owner's CORE token, so an anonymous visitor could otherwise trigger a write action as the owner). New grants default to owner_only; the owner opts into visitor access per integration.
• Audit: every executed action is recorded as a TownActivity row (npc, integration, action, ok) and sent to CORE with a source of town:npc:<id> so it's traceable on both sides.
• Economy: executing an action costs aura, same price as a creator mutation tool; listing/discovery stays free.
• UI: a new owner-only "ACCESS" panel lists connected CORE integrations per NPC, with an expandable per-action whitelist.
• The NPC's system prompt now names its granted integrations so it offers the capability instead of denying it.

Why

Follow-up to #48. The tool surface (list_integrations / list_integration_actions /
execute_integration_action) already existed in npc-tools.ts, but every shipped NPC template ships integrations: [] and the only way to grant one was hand-editing .mdx frontmatter and redeploying. This adds the missing granting surface plus the guardrail and audit trail needed to turn it on safely.

Pairs with the source-attribution change on the core repo (RedPlanetHQ/core, adds source to POST /api/v1/integration_account/:id/action) - this PR is the consumer of that field.

Test notes

• Grant an integration to an NPC via the ACCESS panel, chat as the owner, confirm the tool fires and a TownActivity row + aura debit land.
• Same NPC, visitor session (owner_only left on): integration tools absent from the tool surface entirely.
• Uncheck owner_only, re-test as visitor: tools present.

tools-integration-sample.mp4

[harshithmullapudi]

hey, I think it's misunderstood, the owner of the town already can give access to integrations in mdx. What I meant was the guest who is entering town say Ishu they should be able to give access to their core account so when Ishu signs up with Core account then we should ask if it's ok to give access to say sam for ghost or not.

In the mdx for sam if notion access is taken that mean sam has notion access through core from the owner, what is needed is can ishu also give access to ishu notion account

[harshithmullapudi]

Sorry if this was not clear in the issue

[omjeem]

Hey, @harshithmullapudi

Thanks for the clarification, and sorry for the mix-up - I misunderstood the issue. I built the owner→NPC grant, but I now see what you actually meant: the visitor (Ishu) granting access to their own CORE account, so the NPC acts on the visitor's token, not the owner's. That's a different and bigger change, and you're right that the owner side already exists through the mdx permissions.

Before I propose an approach for the real feature, I'd like to dig a bit deeper and understand it properly from this angle - the visitor-consent flow, where the grant is stored, and routing each integration call to the right person's token (owner vs. visitor). I'd rather come back with a thought-through plan than rush another wrong attempt. Will follow up here once I've mapped it out.

Separately, on this current PR - fully your call: right now the only way an owner sets integration grants is editing .mdx + town deploy. This PR adds an in-game panel to do the same without the CLI. It's convenience over an existing capability, not a new one - and it has a real limitation: a later town deploy would overwrite panel edits, since deploy rebuilds the roster from mdx. Given that, do you want the owner panel as a small standalone QoL thing, or should I just close it and focus on the visitor feature? Either way I'd keep the audit + aura-cost bits, since the visitor feature will need those too.