fix(spec): restore writeOnly on passwordProfile.password + describe PartialSuccess

Two leftover smells from the original v1.0.yaml that the TypeSpec port
had inherited unchanged:

`passwordProfile.password` lost `writeOnly: true` during the migration
because the idiomatic `@visibility(Lifecycle.Create, Lifecycle.Update)`
triggers Read/Update variant generation that collides with the explicit
`@friendlyName("userUpdate")` on `userBase`. Switch to
`@extension("writeOnly", true)` which emits the JSON Schema flag
directly without involving TypeSpec's visibility/variant machinery —
the OpenAPI now carries `writeOnly: true` again, the generated clients
get the matching marker.

`PartialSuccess` (the 207 response on `invite` / `createLink`) carried
a literal `"Partial success response TODO"` description from the
hand-written spec. Replace with a real explanation: `207` means at
least one sub-operation failed (e.g. one invitee out of many couldn't
be granted access), body shape is unspecified, clients should treat
it as a soft failure and inspect server-side state to determine which
sub-operations succeeded.

Author: dschmidt

spec/common.models.tsp

@@ -116,17 +116,17 @@ model passwordProfile {
   @doc("If true the user is required to change their password upon the next login")
   forceChangePasswordNextSignIn?: boolean = false;
 
-  // `writeOnly: true` in the existing v1.0.yaml. TypeSpec's idiomatic
-  // way to express that is `@visibility(Lifecycle.Create, Lifecycle.Update)`,
-  // but applying it here triggers Read/Update variant generation for
-  // every model that transitively references `passwordProfile`
-  // (`userBase`, `educationUser`, …). The auto-variant for
+  // `@extension("writeOnly", true)` emits the JSON Schema `writeOnly`
+  // flag directly. The idiomatic TypeSpec equivalent
+  // `@visibility(Lifecycle.Create, Lifecycle.Update)` would also work
+  // semantically but triggers Read/Update variant generation for every
+  // model that transitively references `passwordProfile`
+  // (`userBase`, `educationUser`, …); the resulting auto-variant for
   // `userResource` then collides with `userBase`'s
   // `@friendlyName("userUpdate")` and the build fails with
-  // `duplicate-type-name: 'userUpdate'`. Dropping the marker is the
-  // smaller cost; `writeOnly: true` is informational and does not
-  // change the resolved schema or the generated client surface.
+  // `duplicate-type-name: 'userUpdate'`.
   @doc("The user's password")
+  @extension("writeOnly", true)
   password?: string;
 }
 

spec/drives.models.tsp

@@ -866,7 +866,14 @@ model CreateLinkResponse {
   @body body: permission;
 }
 
-@doc("Partial success response TODO")
+@doc("""
+  Multi-Status. The operation has completed but at least one sub-operation
+  did not succeed — typically returned by `invite` when the call carries
+  multiple recipients and only some of them could be granted access. The
+  body shape is intentionally unspecified for now; clients should treat
+  `207` as a soft failure and inspect server-side logs or the resource
+  state to determine which sub-operations succeeded.
+  """)
 model PartialSuccess {
   @statusCode _: 207;
 }