feat(cli): add --json output to register, content, and pop commands

[EnderOfWorlds007]

Summary

• Add --json flag to register domain, register subname, content set, content view, pop set, and pop info commands
• Follows the exact pattern already used by bulletin and lookup commands: maybeQuiet() suppresses human-readable output, structured JSON is written to stdout, errors go to stderr
• The underlying viewDomainContentHash and setDomainContentHash functions now return result objects (backward compatible -- callers that ignored the void return still work)
• Registration functions (executeRegistration, executeSubnameRegistration) now return result objects with label, domain, and owner

Motivation

Tools like bulletin-deploy need to programmatically parse CIDs, tx hashes, and status from CLI output. Without --json, they must resort to fragile regex parsing of human-readable output that can break when formatting changes.

JSON output shapes

Command	stdout
register domain --json	{"ok":true,"label":"...","domain":"...dot","owner":"0x..."}
register subname --json	{"ok":true,"label":"...","parent":"...","domain":"...dot","owner":"0x..."}
content view --json	{"domain":"...dot","contenthash":"0x...","cid":"..."} or {"domain":"...dot","contenthash":null,"cid":null}
content set --json	{"ok":true,"domain":"...dot","cid":"...","contenthash":"0x...","txHash":"0x..."}
pop set --json	{"ok":true,"status":"full","statusCode":2}
pop info --json	{"substrate":"...","evm":"0x...","status":"full","statusCode":2}

On error with --json, all commands write {"error":"..."} to stderr and exit non-zero.

Test plan

• Verify dotns register domain --json suppresses human output and prints JSON to stdout
• Verify dotns content view <name> --json returns content hash or null
• Verify dotns pop info --json returns status object
• Verify error cases with --json write to stderr
• Verify all commands without --json behave identically to before (no regressions)

[andrew-ifrita]

Taking a quick look at the surface level.

contentHash.ts still logs to console even when --json is active. We will want to fix that. We should double check any stdout that happens when --json is active.

We will need automated tests in place as well. A simple happy path for the commands you mentioned should suffice.

I see a lot of CI jobs failing because of "Resource not accessible by integration" which I think is a result of coming from a fork. Would you be able to push this straight to this project to clear those up? @EnderOfWorlds007 - from our side a longer term fix would be to have something in place where a maintainer can manually kick off the jobs

[sphamjoli]

@EnderOfWorlds007 Very cool, please ensure you add tests at the various levels which ensures this PR doesnt introduce indirection for other features

[sphamjoli]

Please see comment above

[EnderOfWorlds007]

Closing this fork PR and re-opening from an in-repo branch to fix CI permissions ("Resource not accessible by integration" on fork PRs). See the replacement PR linked below.

Changes in the new PR on top of this one:

• Switched JSON output from process.stdout.write to console.log (and process.stderr.write to console.error) to align with the existing --json pattern in lookup.ts. The test harness only intercepts console.log/console.error, so the previous approach wouldn't have been captured in tests.
• Added code comment explaining why ora spinners are safe inside maybeQuiet: withCapturedConsole replaces .write on the process.stderr object, and ora caches the stream object reference (not the method), so spinner output is captured when the spinner's active lifecycle runs inside the maybeQuiet callback.
• Added unit tests (8 tests): --json flag in help output, JSON error formatting for pre-chain validation errors (conflicting auth options, missing transfer destination).
• Added integration tests (7 tests): content view --json, content set --json, content view --json (unregistered domain), content set --json (error path), pop info --json, pop set --json, register domain --json.