Everything else aside: you fundamentally can't make code released under Apache more restrictive down the road, but you can make code released AGPL3 less restrictive. Permissive licensing is forever, restrictive licensing isn't.
However if either of those preconditions fails, then the reverse becomes true "in practice."
When the copyright is held by multiple parties, re-licensing becomes impractical (or impossible) because every copyright holder needs to agree to the new terms. The more of them there are, the more likely it is that someone will veto.
However, because the AGPL and Apache licenses (and other liberal licenses, MIT, BSD, etc.) are compatible, I can take liberally licensed software, add loads of fancy features using an AGPLv3 license and the combined end result will become AGPLv3 licensed in practice. Just like the combined license of OS X or Chrome is proprietary, even if it contains open source components. The most restrictive license wins.
So assuming the software is evolving over time and you have a wide base of contributors, it is possible to go from less restrictive to more restrictive, but not the other way around.
What do you mean by "relicensing"?
What the Mailpile contributors are doing isn't exactly relicensing. They're just agreeing that from now on their future contributions will be under only one of the two licenses that were a choice in the past. If they choose the Apache license for all new contributions, they can still in the future decide that they want all contributions from that future on to be AGPlv3. If they choose AGPLv3, they can never again without relicensing decide that contributions are no longer copylefted.
I am thus still unable to interpret things as you explain them.
The work is published with a particular license, and that cannot be changed. However, the creators may republish the work with a new license. If this happens third parties can choose which work they want to use, the original published work or the second published (identical) version. By saying that license can only get less restrictive, we mean that people can always choose to use the least restrictive license a work has been published under.
If I have some egregious misunderstanding please correct me.
Sort of, I suppose. A recent example I've been monitoring where this hasn't worked very well is Rhodecode. It was originally GPL'ed and then got locked up into proprietary software (through lies and subterfuge, I must add). The Mercurial folks took the last clearly GPL'ed version and forked it into Kallithea. But Kallithea is not Rhodecode, and Rhodecode has in the meantime added a bunch of development and features that are as restrictive as possible.
I wouldn't take this to mean that Rhodecode is still available under the least restrictive license. The authors have really taken Rhodecode away from us, and we can scamper about with a fork, but there has definitely been some damage done.
Meanwhile: once you publish something MIT/BSD/Apache, it's MIT/BSD/Apache forever; when you try to GPL it, people will simply fork from the MIT code. See: OpenSSH.
As for "you fundamentally can't make code released under Apache more restrictive down the road", isn't that exactly what LibreOffice (LGPLv3) people do when they import patches from Apache OpenOffice (ALv2)?