fix(server): drop writable from host grant results

[hahahahahayesyeseys]

What this changes

Host folder grants are always read-only. Write operations and commands that can edit files are approved separately by the desktop, so the server does not track a writable access mode on a grant.

The desktop result parser nevertheless declared a writable field and normalized it into every accepted grant result. The broker immediately discarded that field, which made the server contract imply an access mode it never stored or enforced.

This removes writable from HostAccessDesktopResult and from the normalized grant object. Extra fields from an older desktop result remain harmless: the parser accepts the result but keeps only the opaque grant id and display name. The broker test now constructs that actual grant shape, and a focused regression test pins the parser output so the field cannot be reintroduced implicitly.

Fixes #735.

Where it runs

This is the server boundary that parses a desktop host-access result. It changes no runtime authorization decision: folder grants remain read-only, while write and writable-command requests still go through the existing native per-operation approval path.

• New state that outlives a request? None. The change removes one field from a transient parsed object.
• What happens on the second replica? Every replica applies the same pure parsing rule; there is no shared or process-local state involved.
• Anything serialised? The normalized server object no longer contains grant.writable. No database or durable format changes.
• Anything fanned out to a browser? No browser payload or socket path changes.
• New listener, port, or schedule? None.

Boundary and audit

• Every acting call still goes through the gateway: this changes only desktop-result normalization, not dispatch or approval.
• No new refusals or failures are introduced.
• Nothing new is trusted from the client. An extra writable value is discarded rather than recorded or used.

Changelog

• No changelog entry. A deployment behaves the same afterwards; this corrects the server's transient result contract to match the existing desktop-owned approval model.

Proof

With the regression test added against 4773ef6 before the source change:

0 pass
1 fail

Expected the grant to contain grantId and displayName only.
Received the same fields plus writable: true.

With the fix:

bun test server/tests/host-access*.test.ts
24 pass
0 fail
76 expect() calls

The repository checks are also clean:

bun run format:check  # 1,254 files checked, no fixes
bun run lint          # 1,269 files checked, no diagnostics
bun run typecheck     # app, server, and worker exited 0
git diff --check      # clean

No screenshot is applicable because there is no UI or deployment-visible behavior change.