workspace: drop --readonly flag — advisory only against root guests

--readonly ran `chmod -R a-w` over the workspace after copying, but
every banger guest boots as root, and root bypasses DAC mode checks.
So a user running `vm workspace prepare ... --readonly` got the
mode bits set to 0444 but `echo x >> file` in the guest still
succeeded. The flag promised enforcement it couldn't deliver.

The feature also doesn't match the product model: workspaces are
prepared precisely so the guest CAN edit them, and `workspace
export` exists to pull those edits back as a patch. A
"read-only workspace" contradicts that loop.

Removed:
  - CLI flag `--readonly` on `vm workspace prepare`
  - api.VMWorkspacePrepareParams.ReadOnly field
  - model.WorkspacePrepareResult.ReadOnly field
  - daemon chmod dispatch in prepareVMWorkspaceGuestIO
  - smoke scenario pinning the (advisory) mode-bit behavior
  - misleading "exportbox-readonly" VM name in an unrelated export
    test (the test is about not mutating the real git index;
    renamed to exportbox-noindex-mutation)

If real enforcement becomes a user need later, the right primitive
is `chattr +i` (immutable bit — root CAN'T write) or a ro bind-mount.
Reintroducing a new flag is cheaper than debugging what the current
one actually guarantees.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

internal/model/types.go

@@ -172,7 +172,6 @@ type WorkspacePrepareResult struct {
 	RepoName      string               `json:"repo_name"`
 	GuestPath     string               `json:"guest_path"`
 	Mode          WorkspacePrepareMode `json:"mode"`
-	ReadOnly      bool                 `json:"readonly"`
 	HeadCommit    string               `json:"head_commit,omitempty"`
 	CurrentBranch string               `json:"current_branch,omitempty"`
 	BranchName    string               `json:"branch_name,omitempty"`