fix: read pico gateway token from security.yml dynamically

[BeaconCat]

Summary

Fix token desync between NanoKVM-Server and PicoClaw gateway after PicoClaw restarts.

Problem

When PicoClaw restarts, it regenerates the pico channel token. NanoKVM-Server was caching the old token, causing authentication failures on the gateway endpoint.

Solution

GetPicoclawInternalToken() now reads the token directly from ~/.picoclaw/.security.yml on every call instead of using a cached value.

Fallback chain: security.yml → cached → legacy token file → generate new

Files changed

• server/config/picoclaw_internal.go (new file)

[wj-xiao]

Thanks for your hard work.

I don’t think GetPicoclawInternalToken() should read ~/.picoclaw/.security.yml.

That function validates NanoKVM loopback/internal requests via X-NanoKVM-Internal-Token, including internal routes outside PicoClaw. The token in .security.yml belongs to the PicoClaw pico channel/gateway auth path, so this change merges two separate trust domains.

It also creates a fresh-install desync. ensurePicoclawStartupDefaults() calls applyPicoclawStartupDefaults() first, which writes the MCP server header using GetPicoclawInternalToken(). Only after that does it call ensurePicoclawPicoToken() to generate and save the PicoClaw token into .security.yml. PicoClaw can then be configured with one header token while NanoKVM validates against a different token on later requests, causing 401s on /api/picoclaw/mcp.

I’d keep GetPicoclawInternalToken() backed by /etc/kvm/.picoclaw_internal_token and fix the gateway desync instead. The gateway connection path should refresh loadPicoclawGatewaySettings() / .security.yml before dialing PicoClaw, so the Authorization: Bearer ... token stays current.