Struct RewriteOutcome 

pub struct RewriteOutcome {
    pub bytes: Vec<u8>,
    pub opened_slot: u16,
    pub slot_used: usize,
    pub carried_opaque: usize,
    pub may_have_evicted: bool,
}

slot 区改写的结果。

Fields

bytes: Vec<u8>

改写后的完整文件字节。

opened_slot: u16

解开原文件时命中的 slot 下标，供调用方展示。

slot_used: usize

改写后占用的 slot 数量（即传入的 KEK 个数）。

carried_opaque: usize

原样搬运过来的、来历不明的槽数量。

这个数字不代表「还有几个密码」：它把真实的其它密码和随机填充 算在了一起，因为两者在字节层面本就不可区分（可否认性）。 所以 UI 不能拿它说「保留了 N 个密码」——那是它并不知道的事。

它唯一的正当用途是端到端验证：断言「搬运策略下这个数是 7， 清场策略下是 0」，从而证明两条路径真的走了不同实现。

may_have_evicted: bool

本次操作是否可能顶掉了原先占着这些下标的槽。

keep 里的 KEK 占据 slot 0..n，搬运只能从 n 开始。所以当 keep 比文件原有的密码数更多时（典型是 add），原本在 slot n 上的槽会被 新密码盖掉——而我们无法知道那里原来是真密码还是随机填充。

为 true 时调用方应提醒用户：这次新增可能作废了此文件上的某个 其它密码（如恢复码）。不能断言「一定作废了」，那同样是我们不知道 的事；只能如实说「可能」。

判据是 keep.len() > 1：只保留一个密码时（change / remove） 不存在增长，slot 0 本来就会被重写。

Trait Implementations

impl Debug for RewriteOutcome

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.