Add presence set-preferred and clear-preferred

[aberoham]

presence set-preferred and presence clear-preferred manage the user-preferred presence, which Microsoft Graph ranks above every presence session while one exists.

• The Teams client's "Appear offline" is a preferred presence of Offline/OffWork. With it set, presence set returns success and the account stays offline, and no command could clear it.
• set-preferred --availability A [--expiration D] calls setUserPreferredPresence. Graph accepts Available, Busy, DoNotDisturb, BeRightBack, Away and Offline, each with one fixed activity, so the activity is derived from the availability and reported back.
• --expiration is checked as a positive ISO 8601 duration and not bounded. Graph documents defaults of one day for Busy and DoNotDisturb and seven days otherwise, rather than a range, so the PT5M to PT4H check on set does not apply here.
• clear-preferred calls clearUserPreferredPresence with the documented {} body. A second clear with nothing to clear returns 200, so there is no 404 to translate.
• Both commands reject an app-only token locally, as the other presence writes do.
• README, command reference, man page, CHANGELOG and the command lists in CLAUDE.md and AGENTS.md are updated.

Sample output:

{"status": "preferred_presence_set", "availability": "Away", "activity": "Away", "expiration_duration": "PT1H"}

{"status": "preferred_presence_cleared"}

Verified against a live tenant on 2026-09-03: an account carrying Offline/OffWork with an open Available session read Available/Available after clear-preferred; set-preferred --availability Away read Away/Away through both presence get and presence get-batch; a second clear-preferred returned 200.

[aberoham]

Adversarial review completed against base 979791f through the updated head 90466fe.

Findings fixed:

• In 06a655f, the duration parser was fixed to reject malformed P1DT. A trailing T had been treated as an empty but valid time section, allowing an invalid value to reach setUserPreferredPresence despite the command promising local ISO 8601 validation. Unit and black-box regression coverage were added.
• In 06a655f, exact v1.0 /me presence endpoint assertions were added. The previous Wiremock tests injected URLs and therefore did not cover the production endpoint builders.
• In 06a655f, command-path coverage for app-only rejection and help-JSON coverage for both new subcommands and the required availability flag were added; the auth guide and PRD command documentation were completed.
• In 06a655f, the docs were clarified to state that the CLI accepts positive whole-unit day/hour/minute/second durations rather than every possible ISO 8601 duration form.
• In 90466fe, the locked optional rand dependency was updated from 0.9.2 to patched version 0.9.3, clearing informational unsoundness advisory RUSTSEC-2026-0097. The affected dependency was only present through the unused optional HTTP/3/Quinn path in Reqwest, and the CLI has no direct Rand use or custom log::Log implementation, so I found no reachable exploitation path; the update removes the advisory regardless.

Validation completed:

• cargo audit: clean; 321 dependencies scanned
• cargo fmt -- --check
• cargo check --all-targets
• cargo clippy --all-targets -- -D warnings
• cargo test --all-targets: 250 unit tests and 69 black-box tests passed
• cargo build --release
• Direct probes confirmed malformed P1DT exits 2 while valid P1DT1S proceeds to authentication

I also checked the current Microsoft Graph v1.0 documentation for setUserPreferredPresence and clearUserPreferredPresence against the URL, request-body, pair, default-expiration, response, and delegated-permission behavior used here. I did not repeat the live-tenant writes already documented in the PR.

The fork-origin GitHub Actions run currently shows action_required with no jobs, so hosted Ubuntu/macOS/Windows CI remains pending approval.

No further code, dependency, or documentation findings remain. Merge-ready once hosted CI is approved and passes.

[sionsmith]

Reviewed and verified locally:

• fmt, clippy (-D warnings), the full suite, cargo build --locked and cargo audit all pass; the rand 0.9.3 bump clears RUSTSEC-2026-0097 from the audit.
• Microsoft Learn agrees with every design choice: setUserPreferredPresence takes one fixed activity per availability (Offline/OffWork included), expirationDuration is an ISO 8601 duration with documented defaults of one day for Busy/DoNotDisturb and seven days otherwise and no documented range, so deriving the activity and not bounding the expiration is right. The PT5M–PT4H range belongs to setPresence only. Delegated Presence.ReadWrite covers both actions and is already in the default scope set.
• The mocked tests pin the wire shape, including the {} body for clearUserPreferredPresence. I could not exercise it live: the sandbox token predates Presence.ReadWrite joining the defaults.

Extended the branch with a ### Changed changelog entry for the uuid and rand refreshes (the lockfile change had no entry), and rebased onto main so the changelog merges with #90 and #91. Merging once CI is green.

[sionsmith]

@aberoham two questions from the live run you did on 2026-09-03, since our sandbox session predates Presence.ReadWrite joining the default scopes and cannot exercise these writes until it is re-consented:

1. You saw 200 from a second clearUserPreferredPresence; Microsoft Learn documents 204 No Content for both actions. Did setUserPreferredPresence and the first clearUserPreferredPresence also answer 200, or only the no-op clear? Either is handled, I just want the observed codes on record in case Graph changes them.
2. After set-preferred --availability Away, did presence get reflect Away/Away immediately, or after a delay? And did the re-login that added Presence.ReadWrite go through with user consent alone, no admin prompt, in your tenant?

Thanks, it is in main and will ship in the next release.