Refactor shared-drive office open flow to use drive proxy path (owner as source of truth)

[shepilov]

Problem

Shared-drive office open currently uses a custom cross-instance flow (model/sharing/open_office.go) instead of the standard drive proxy path used by most /sharings/drives/:id/... routes. This creates mixed semantics in response payloads (instance from owner, public_name overwritten locally, historically onlyoffice manipulation) and increases maintenance risk.

Currently:

• Bob calls GET /sharings/drives/:driveId/office/:fileId/open on Bob stack.
• Bob stack fetches owner /office/:fileId/open with drive token.
• Bob's stack post-processes the payload before returning to UI.

Proposed:

• GET /sharings/drives/:driveId/office/:fileId/open should follow the same proxy pattern as other shared-drive file routes (drives.go).
• Owner stack returns canonical office payload.
• The recipient's stack forwards it without special office-specific rewrites.

[taratatach]

This sounds good to me. My only concern would be leaking OnlyOffice related secrets from the owner instance that would allow Bob to circumvent our permission system.
But maybe there are no such secrets?!