Portal: the per-share management switch, in the console and in the sharing table

[Daily-AC]

Stacked on feat/shared-inherits-owner-rights (#61). Retarget to main once that
merges.

Fixes #48

Summary

The portal half of ADR 0007's per-share management switch, built on #61's
contract: manage on shared rows of /api/devices and on every /api/acl row,
POST /api/acl/manage to flip one, POST /api/acl to create with it. Field
names match the contract exactly; nothing needed renaming.

Device page. mayAdminister is the single predicate for who may drive a
device's control plane — your own devices always, a shared one only when its
grant carries manage. It replaces reads of .shared that were deciding the
same thing in six places, and mirrors #61's requireDeviceConsole. The guard
that was one guard is now two, because the two questions now have different
answers: adminGuard covers approvals, pairing, trust, rules and mode;
roGuard stays on alias, unbind, Feishu, notify and ADB, which are the owner's
rather than the device's. A managed share gets the console the owner sees, with
a banner naming the owner in both languages, because the screen underneath is
otherwise indistinguishable from your own. The gear stays hidden on every shared
device: everything behind it belongs to the owner, so the switch reaches none of
it, and hiding it removes a screen whose every control would refuse.

Sharing table. The permissions column is gone, since every share now carries
the same set, and the switch that does vary takes its place using the same .sw
control as elsewhere. Turning it on asks first, through the theme sheet, because
it hands over the approvals, trust, rules and mode of someone else's machine.
Turning it off does not ask: making someone stop and confirm a revocation is how
you get people not to revoke. The share form carries the same switch, off by
default; formBox grew a checkbox field to hold it.

Audit tables, both copies: SEC-B-01 and SEC-C-02 are narrowed rather
than superseded, and SEC-B-01 records the three-way split. I would have left
these rows to #61 as you asked, but its text still says "there is no read-only
share", which the default share now is — so it contradicts what the portal does.
Hand them back to the #61 agent if you would rather; the rows are self-contained
and I will drop my version.

The activity log is a use right

Decided separately, and built here. wanctl logs already works for every
grantee, so gating the same log behind the management switch in the portal would
recreate the split ADR 0007 removed: the same person, the same device, allowed
in one client and refused in the other.

requireDeviceUse joins the other two gates — the owner, or anyone holding a
live share, whatever the switch says — and events and logs move onto it. The
switch keeps deciding who may change a device, which is what it was for.

On the page, a read-only share shows the Activity tab and opens on it, because
it is the only tab with anything in it. Waiting and Trust & rules are hidden
rather than shown dead: a tab that opens onto "only the owner can answer this"
is a worse answer than not offering the tab.

Three route kinds, three answers:

	manage=false	manage=true
decide, pair, untrust, rules, mode, identity/accept, adb-pair	403	admitted
events, logs	admitted	admitted
lark, notify	403	403

sharedread_test.go asserted the opposite for events and logs, so its first
case drops them and states why, and the other half of the decision gets its own
case.

Also fixes #48

I reported earlier that #48 was not reproducible. That was wrong, and this
fixes it. I had tested only the entry where the hash is already in the URL at
load; that fires no hashchange and never races. The path that races is a hash
set during load: the event is queued before the listener exists and delivered
after it, so route() runs before /api/devices resolves.

loadDevices already knew about this and repaired the device name and the alias
field, and left every access-dependent conclusion at its empty-devMeta value.
A shared device drew as if it were yours: gear showing, mode chip live, no
banner, blank fingerprint. It never healed, because nothing re-ran. Measured
before and after at the same URL:

	fingerprint	banner	gear hidden
before, at 2s	empty	hidden	not set
before, at 5s	empty	hidden	not set
after	present	shown	set

The gating is now one function called both when the page opens and again when
the device list lands, with an idempotent console start so the second pass opens
no second poll. Verified load-bearing by removing the repair again: six
assertions fail across both widths.

Test plan

gofmt -l . clean, go vet ./... and go vet -tags lark ./... clean,
go test ./... and go test -tags lark ./... pass.

Go — the mutation routes

sharedread_test.go in #61 covers five read routes. The routes that change a
device were left to inference, and they are the ones worth getting wrong. Added
a table over the seven control-plane mutations plus the two owner-only ones,
with the switch off and on: 18 subtests.

$ go test ./internal/portal/ -run TestSharedDeviceMutationRoutesFollowTheManagementSwitch -v
    22 subtests, all PASS

Each refusal also asserts the relay was never reached — a gate that answers 403
after already fetching the owner's console has still read it. Verified
load-bearing by making requireDeviceConsole ignore access.Manage: every
manage=true control-plane row fails, owner-only rows keep passing.

Browser — shared devices

tools/portalpreview/shared-device.mjs, both kinds of share, both widths, both
entry paths:

共享设备门禁：22 次检查全部合格
  只读共享：齿轮不可见 · 模式胶囊不可交互 · 横幅在 · 指纹已填 · 无审批按钮 · 只剩活动一页且有内容 · 设置地址退回设备页
  可管共享：控制面在（审批按钮、模式胶囊）· 横幅点出设备主人 · 通知/飞书/解绑一律不可见

Verified load-bearing three ways: removing the [hidden] rule surfaces the
gear, removing the settings redirect surfaces the settings screen, and leaving
the two tabs visible for a read-only share produces six failures across both
widths.

Browser — the Manage column

Driven through the real handlers and the theme sheet, at 1200 and 390, in both
languages:

check	result
two rows, one switch each	yes
manage:false row renders off, aria-pressed="false"	yes
manage:true row renders on, aria-pressed="true"	yes
no permissions string rendered anywhere	yes
turning on opens the theme sheet, no native dialog	yes
request sent	POST /api/acl/manage {"device":"bench-02","grantee":"rowan","manage":true}
row reflects the flip	yes
turning off asks nothing and flips	yes
share form has the switch, default off, no perms key	yes

Fixtures gain quarry, a managed share with a pending approval, a pending
pairing, a rule and a trusted controller, because a state that renders
identically to another is not one the harness can see; a second ACL row so the
column shows both states; and a real write for /api/acl/manage, so the switch
does not spring back after a successful flip.

Two things for you

This branch carries a merge of main. #61 is two commits behind main and does
not contain #59, including [hidden]{display:none!important} — which is exactly
what keeps the gear hidden on a shared device, so without it the shared-device
guard fails on the assertion it exists for. I merged origin/main in rather than
regress that. The consequence is that the diff against #61's branch also shows
#59 and #62. Rebasing #61 onto main would clear it; I did not touch someone
else's branch.

#61 puts /api/devices/adb-pair behind requireDeviceConsole, so a grantee
with manage may pair ADB over the API. The portal never offers it to them: the
ADB card lives behind the gear, which is hidden on every shared device. Not a
hole — the server check is the real one — but the UI and the API disagree about
who may do it, and one of the two should move. My reading is that ADB pairing is
device setup rather than device operation and belongs with the owner, but it is
#61's call.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SpPAyRQzTAw7MbmJqZdm7e