Agent registration management

Problem to be solved

Our trycloudflare links are still pretty impermanent, websites, skills, etc go out of date (often for relying on latest tags too, different issue).

Proposed solution

Have the cli (and internal and external agents) manage the updating of agent registration to match the current tunnel with a set metadata call. Log approximately how much gas will be consumed / was consumed in u.Dim(). trigger this clean up if we detect a tunnel change? service rich metadata on the domain?

Out of scope

(but worth discussing)

what if we do a --publish equivalent to our launchpad, and give them a more persistent place for discovery (and maybe tunnelling?). something like pet-name.agent.obol.tech (or .dev or something), and allow them to CRUD metadata there? (imo it depends on how good decentralised finding services through 8004 is, could we watch for registrations? would that restrict us to eth funders only? whereas if they call us directly they don't need to go on chain to display them.

Start by locating the CLI and internal and external agent registration paths, then review how the current tunnel and 8004 metadata calls are represented. Clarify the required set-metadata behavior, tunnel-change trigger, and gas reporting before implementation. Done means registration matches the current tunnel and metadata updates are observable with gas estimates or usage.