Show profile save behavior in browser tables

[IlyaasK]

What

• add a Save Changes column to kernel browsers list
• show Save Changes in human-readable create, get, and browser-pool acquire result tables
• render explicit true and false values while preserving omission when the API did not return the field
• add coverage for list and detail table rendering

Why

kernel/kernel#3177 added profile_save_changes to browser responses, and kernel-go-sdk v0.87.0 generated the corresponding field. JSON output already included it automatically, but human-readable tables hid it, making it harder to identify sessions that can overwrite a profile.

The CLI's current main branch already depends on kernel-go-sdk v0.87.0, so no additional SDK dependency bump is needed in this PR.

Behavior

Before, human-readable browser output showed the attached profile without indicating whether the session would save changes. After this PR, it displays Save Changes as true or false; list output uses - when the response omits the field.

Verification

• GOCACHE=/private/tmp/kernel-cli-profile-save-gocache make test
• focused browser table tests
• git diff --check

---

Note

Low Risk
CLI display-only changes with no request or persistence logic; low risk aside from table layout.

Overview
Human-readable browser output now surfaces profile_save_changes from the API, which JSON output already exposed.

kernel browsers list gains a Save Changes column. Create, get, and pool-acquire result tables show a Save Changes property when the field is present. A shared formatProfileSaveChanges helper prints true/false only when the SDK marks the field valid; otherwise list rows use - and detail tables omit the row.

Tests cover list output and buildBrowserTableData omission vs display behavior.

^{Reviewed by Cursor Bugbot for commit e1230d6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[sjmiller609]

thanks for putting this together. the browser tables intentionally show a curated subset of response fields, while the full response is available through --output json. the upstream request was for API visibility rather than human-readable CLI output.

if there isn't a concrete request to include this in the default CLI output, then I advise closing out this PR