Fix the presence write commands

[aberoham]

Default delegated logins omitted the permission all three presence-write
commands need. presence set and presence clear also sent an invalid or
missing sessionId. Reproductions and the Graph responses are in #70 and #71.

Default scopes (#70)

setPresence, setStatusMessage and clearPresence all require the delegated
Presence.ReadWrite permission, which DEFAULT_DELEGATED_SCOPES did not
request. Microsoft does not mark it admin-consent required, so it
can join the default set. docs/auth.md and docs/faq.md now list it with the
rest.

Existing sessions keep the scopes they were granted, so users need to run
teams auth login again. auth refresh cannot add a scope that was never
consented to. That instruction only reaches logins that take the defaults:
--scopes, TEAMS_CLI_SCOPES and a profile's scopes field replace the
default set rather than extend it, so a login that names its own scopes has to
restate the whole list with Presence.ReadWrite in it. README.md and
docs/auth.md say so.

Deployment follow-up, outside this PR: verify whether the OSO app
registration's static delegated-permission list also needs updating.

Session ID (#71)

Graph identifies a presence session by the application that owns it, and both
setPresence and clearPresence document that application's ID as the
sessionId they expect. clearPresence was sent an empty body; setPresence
sent a new random UUID on every invocation.

Both now use a configured client ID — TEAMS_CLI_CLIENT_ID or the profile's
client_id — when there is one, because that names the application directly
and Microsoft asks callers to treat access tokens as opaque. Otherwise the
value comes from the token's own claims, preferring azp and falling back to
appid, matching redeem_refresh_token's claim order; that is the path a
login through the built-in application takes, since it configures no client ID.
Blank values are skipped, and a token with no usable application-ID claim and
no configured client ID fails with an auth error rather than a guess. set and
clear agree either way, because both resolve the value the same way.

Clearing a session that is not there

Graph answers 404 when the application has no presence session to clear, which
is the state clear exists to reach, so a second clear — or a retry after an
ambiguous response — failed against presence that was already automatic. That
answer is no longer an error.

It is not the same outcome as closing a live session: a session opened under a
different application ID answers the same way. clear reports which one Graph
gave, presence_cleared or no_presence_session, and both set and clear
report the session ID they used, so a clear run under different configuration
than the set is visible rather than silent. A retry whose earlier attempt
succeeded but lost its response also sees 404, and the prose says so.

Tests

wiremock asserts the serialized setPresence and clearPresence payloads, and
covers clearPresence answering 404 directly and answering it after a retried
503. Unit tests cover default-scope membership and session-ID selection: a
configured client ID winning over the token, a blank one falling through, an
opaque token accepted when a client ID is configured, and the azp/appid
order, blank claims and undecodable tokens on the fallback path.

Not covered

--expiration is still passed through without local validation. Presence writes
also do not reject app-only tokens locally, unlike message writes, which call
require_delegated_token.